
Y28-6601-2 



Program Logic 



IBM System/360 Operating System 

FORTRAN IV (E) 
Program Logic Manual 

Program Number 360S-F0-092 



This publication describes the internal 
design of the IBM System/360 Operating 
System FORTRAN IV (E) compiler program. 
Program Logic Manuals are intended for use 
by IBM customer engineers involved in pro- 
gram maintenance, and by system programmers 
involved in altering the program design. 
Program logic information is not necessary 
for program operation and use; therefore, 
distribution of this manual is limited to 
persons with program maintenance or modi- 
fication responsibilities. 



Restricted Distribution 



PREFACE 



This manual is organized into three 
sections. Section 1 is an introduction and 
describes the overall structure of the 
compiler and its relationship to the oper- 
ating system. Section 2 discusses the 
functions and logic of each phase of the 
compiler. Section 3 includes a series of 
flowcharts that show the relationship among 
the routines of each phase. Also provided 
in this section are phase routine director- 
ies. 

Appendixes at the end of this publica- 
tion provide information pertaining to: 
(1) source statement scan, (2) intermediate 
text formats, (3) table formats, (4) main 
storage allocation, etc. 



Although not prerequisite, the following 
documents are related to this publication: 



IBM System/360 Operating System: FORTRAN 
IV (E) Library Subprograms , Form 
C28-6596 



IBM System/360 Operating System: Sequen- 
tial Access Methods, Program Logic Manu- 
al. Form Y28-6604 



IBM System/360 Operating System: Con- 
cepts and Facilities , Form C28-6535 



Prerequisite to the use of this publica- 
tion are: 

IBM System/360 Operating System: Princi- 
ples of Operation , Form A22-6821 

IBM System/360 Operating System: FORTRAN 
IV (E) Language , Form C28-6513 

IBM System/360 Operating System: Intro- 
duction to Control Program Logic, Pro- 
gram Logic Manual , Form Y28-6605 



IBM System/360 Operating System: Control 
Program Services , Form C28-65U1 

IBM System/360 Operating System: Linkage 
Editor, Program Logic Manual , Form 
Y28-6610 

IBM System/360 Operating System: Data 
Management , Form C28-6537 

IBM System/360 Operating System: System 
Generation , Form C28-6554 



IBM System/360 Operating System: FORTRAN 
IV (E) Programmer's Guide , Form C28-6603 
(sections "Job Processing" and 
"Cataloged Procedures") 



This compiler is similar in design to 
the IBM System/360 Basic Programming Sup- 
port FORTRAN IV Compiler. 
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This is a major revision of, and obsoletes, Form Y28-6601-1. Signifi- 
cant changes have been made throughout the text. This edition should be 
reviewed in its entirety. 
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(1) compile-time and object-time processing of direct access statements, 

(2) dynamic text buffer chaining, (3) removal of restrictions on source 
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impressions for photo-offset printing were obtained from an IBM 1403 
Printer using a special print chain. 
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SECTION 1: INTRODUCTION 



This publication describes the internal 
logic of the FORTRAN IV (E) compiler, which 
translates source modules written in the 
FORTRAN IV (E) language into machine- 
language object modules. The object 
modules are used as an input to the linkage 
editor program, which produces load modules 
for execution on the IBM System/360. If 
the compiler detects errors in the source 
modules, appropriate error messages are 
produced. 



THE COMPILER AND OPERATING SYSTEM/ 3 60 



The FORTRAN IV (E) compiler is a pro- 
cessing program of the operating system 
and, as such, communicates with the follow- 
ing parts of the operating system control 
program: 

• Job management routines that analyze 
job control language statements. 

• Task management routines that allocate 
main storage for use by the compiler. 

• Data management routines that read data 
from and write data onto input/output 
devices. 

The execution of the compiler (i.e., a 
single compilation, or a batch of 
compilations) is introduced as a job step 
under the control of the operating system 
via the job statement (JOB), the execute 
statement (EXEC) , and data definition 
statements (DD) for the input/output data 
sets. To keep these statements at a mini- 
mum in the job stream, cataloged procedures 
are provided. A discussion of the execu- 
tion of the compiler as a job step and of 
the available cataloged procedures is given 
in the publication IBM System/360 Operating 
System: FORTRAN IV (E) Programmer's Guide . 



THE INTERFACE MODULE 



The interface module, a component of the 
FORTRAN IV (E) compiler, resides on the 
operating system library (SYS1.LINKLIB) . 
This module is loaded, via the LOAD macro- 
instruction, into main storage and remains 
in main storage until control is returned 
to the calling program. The interface 
module processes all read/write requests of 
the compiler using the BSAM (basic 
sequential access method) read/write rou- 
tines. A description of BSAM and the 
corresponding read/write routines is given 
in the publication IBM System/360 Operating 
System: Sequential Access Methods, Program 
Logic Manual . 



SYSTEM MACRO-INSTRUCTIONS 



Whenever the XCTL, LOAD, DELETE, OPEN, 
OPEN (type=J), CLOSE, CLOSE (type=T) , READ, 
WRITE, CHECK, RDJFCB, GETMAIN, FREEMAIN, 
BLDL, SPIE, or TIME macro-instruction is 
issued, control is given directly to the 
operating system to execute the requested 
service. 

When the execution of the compiler is 
terminated, control is returned to the 
calling program via the RETURN macro- 
instruction. 

For a description of these macro- 
instructions, refer to the publication IBM 

System/360 Operating System: Control 

Program Services. 



COMPILER ORGANIZATION 



In addition, any job step may invoke the 
compiler via the LINK or ATTACH macro- 
instruction. 

The compiler initially receives control 
from the calling program via a supervisor- 
assisted linkage. Once the compiler 
receives control, it maintains communi- 
cation with the operating system through: 

• The interface module. 

• System macro- instructions. 



The FORTRAN IV (E) compiler consists of 
several components, each of which exists as 
a separate load module on the operating 
system library (SYSl.LINKLIB) . The compo- 
nents are: 



• Phases (1, 5, 7, 8, 10D, 10E, 
15, 20, 25, and 30). 

• Interludes (10E, 14, and 15). 

• Interface module. 

• Performance module. 

• Source symbol module. 

• Object listing module. 



12, 14, 



Section 1: Introduction 



The compiler components, their symbolic 
names, and their major functions are sum- 
marized in the discussion of overall com- 
piler operation (refer to Table 1). 



COMMUNICATION AMONG COMPILER PHASES 



Communication among the phases of the 
FORTRAN IV (E) compiler is implemented via: 

• The communication area. 

• Intermediate text. 

• Resident tables. 



THE COMMUNICATION AREA 



The communication area is a central 
gathering area (a portion of the interface 
module) for information common to the phas- 
es. It is used to communicate this infor- 
mation, when necessary, among the phases. 



reference numbers used in the source 
module. (For SPACE compilations, the dic- 
tionary resides in main storage only 
through the execution of Phase 14.) The 
overflow table contains all dimension, sub- 
script, and statement number information 
within the source module. SEGMAL is used 
for main storage allocation within the 
compiler. The patch table contains infor- 
mation to be used to modify compiler compo- 
nents. The blocking table contains infor- 
mation necessary for deblocking compiler 
input and blocking compiler output for 
PRFRM compilations. The BLDL table pro- 
vides the information necessary for trans- 
ferring control from one component to the 
next for PRFRM compilations. The reset 
table is used to determine which, if any, 
of the record counts for the SYSUT1 and 
SYSUT2 data sets must be reset. (The 
blocking table, the BLDL table, and the 
reset table reside in main storage only for 
PRFRM c ompi la t i ons . ) 



COMPILER INPUT/OUTPUT FLOW 



INTERMEDIATE TEXT 



Source module statements (both executa- 
ble and nonexecutable) are converted into 
intermediate text. This intermediate text, 
once it is created, is used as input to the 
subsequent phases of the compiler. The 
intermediate text for the executable state- 
ments is eventually transformed into 
machine-language instructions. 



The initial input (source modules) to 
the compiler is provided in the form of 
cards or card images on intermediate stor- 
age, and is read into main storage from the 
SYSIN data set. The compiler uses SYSUTl 
and SYSUT2 as intermediate text work data 
sets. If the buffers to be used for 
reading from and writing onto these work 
data sets are large enough to contain the 
intermediate text representation of the 
source module, then this text is retained 
in main storage. 



RESIDENT TABLES 



The resident tables contain information 
that remains in main storage throughout the 
compilation process. The resident tables 
are the dictionary, the overflow table, the 
segment address list (SEGMAL) , the patch 
table, the blocking table, the BLDL table, 
and the reset table. The dictionary is a 
reference area containing information about 
variables, arrays, constants, and data set 



The output of the compiler is placed 
onto the SYSPRINT, SYSLIN, and SYSPUNCH 
data sets as specified by the user. SYS- 
PRINT is always used. SYSLIN is used only 
if the LOAD option is in effect. SYSPUNCH 
is used only if the DECK option is in 
effect. 



Figure 1 shows the various compiler 
options that are available for obtaining 
compiler output . 
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Figure 1. Compiler Input/Output Structure 



OVERALL COMPILER OPERATION 



The overall operation of the compiler 
involves the following general functions: 

• Initialization (Phases 1, 5, and 7). 

• Source statement adjustment if required 
(Phase 8). 

• Source statement scanning (Phases 10D 
and 10E) . 

• Translation of the source module 
(Phases 10D, 10E, 14, 15, and 20). 

1. Intermediate text generation 
(Phases 10D and 10E) . 

2. Intermediate text modification 
(Phases 14, 15, and 20). 

• Object module generation (Phases 12, 
14, 20, 25, and 30). 

• Storage map generation (Phases 12, 20, 
and 25). 

• Diagnostic message generation (Phase 
30). 



The manner in which control is trans- 
ferred among the compiler components 
depends on whether the SPACE or PRFRM 
option is specified by the user. The SPACE 
option is chosen if the amount of main 
storage that is available for compilation 
is limited. The PRFRM option is chosen if 
the user desires maximum compiler efficien- 
cy and if the amount of available main 
storage is not a limitation. 

If the SPACE option is specified, con- 
trol is transferred among the compiler 
components via the interface module. After 
each component has been executed, that com- 
ponent branches to the interface module 
with the name of the component to be 
executed next. The interface module then 
transfers control to the next component via 
the XCTL macro-instruction. 

If the PRFRM option is specified, con- 
trol is transferred among the compiler 
components via the performance module. 
After each component has been executed, 
that component branches to the interface 
module with the name of the component to be 
executed next. The interface module, in 
turn, branches to the performance module. 
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If the next component is an interlude, the 
performance module bypasses the execution 
of the interlude and transfers control, via 
the XCTL macro- instruction, to the next 
phase of the compiler. If the next compo- 
nent is a phase, the performance module 
immediately transfers control to the next 
phase. 

Figure 2 illustrates the overall compil- 
er input/output flow and includes inter- 
mediate input to and from the various 
phases of the compiler. 

Chart 00 shows the overall compiler 
control flow. Table 1 summarizes the major 
functions performed by each component of 
the compiler. 



Communication area 
(Phases 1, 5, and 7). 



initialization 



For a subsequent compilation in a batch, 
the initialization steps depend on whether 
the SPACE or the PRFRM option is in effect. 

If the SPACE option is in effect, subse- 
quent compilations in a batch are initial- 
ized in the following manner: 

• All the remaining main storage, origi- 
nally obtained and allocated to the 
compiler by Phase 5 is freed (Phase 1) . 



All the data control 
compiler data sets are 
1). 



blocks for the 
closed (Phase 



INITIALIZATION (PHASES 1, 5, AND 7) 



Certain initialization steps must be 
performed prior to any source module pro- 
cessing. The steps that are performed 
depend on whether the first compilation or 
a subsequent compilation in a batch is 
being initialized. 

For the first compilation in a batch, 
initialization consists of the following 
functions : 



• The remaining initialization steps per- 
formed for a subsequent compilation in 
a batch SPACE run are the same as those 
described for the first compilation in 
a batch starting with the opening of 
the data control blocks. 

If the PRFRM option is in effect, only 
the dictionary and overflow table (in Phase 
7) , and the communication area (in Phases 1 
and 7) are initialized. 



SOURCE STATEMENT ADJUSTMENT IF REQUIRED 
(PHASE 8) 



• Loading the interface module into main 
storage (Phase 1) . 

• Processing compiler options (Phase 1) . 

• Loading the source symbol module into 
main storage if the object listing 
option is in effect and if the object 
listing facility of the compiler has 
been enabled (Phase 1). 

• Loading the performance module into 
main storage if the PRFRM option is in 
effect and if the SIZE option is at 
least 18,504 (Phase 1). 

• Opening required data control blocks 
for the data sets used by the compiler 
(Phase 1). 

• Loading Phase 5 into main storage 
(Phase 1) . 

• Obtaining and allocating main storage 
for use by the compiler (Phase 5) . 

• Constructing text buffer chains for the 
SYSUT1 and SYSUT2 data sets if the 
PRFRM option is in effect (Phase 5). 

• Resident table initialization (Phases 5 
and 7) . 



Any source statements written with 
embedded blanks and keywords used as varia- 
bles, arrays, or external names are adjust- 
ed by the compiler (if the ADJUST option is 
in effect) into a format that is acceptable 
as input to Phases 10D and 10E. Phase 8 
eliminates embedded blanks; adds a special 
character to keywords that are used as 
variables, arrays, or external names; and 
inserts a meaningful blank between succes- 
sive words in a FORTRAN statement. In 
addition, if the SOURCE option is in 
effect. Phase 8 produces a listing of the 
unadjusted source module. 



SOURCE STATEMENT SCANNING (PHASES 10D AND 
10E) 



The main purpose of source statement 
scanning is to convert each source state- 
ment into a form (intermediate text) that 
is usable as input to subsequent phases of 
the compiler. If the SOURCE and NOADJUST 
options are in effect, Phases 10D and 10E 
produce a listing of the source module. In 
addition, as source statements are scanned, 
they are checked for validity and any 
errors that are detected are indicated by 



12 



developing special intermediate text. 
(Phase 30 produces diagnostic messages from 
this intermediate text that explain the 
errors that are detected. ) 



TRANSLATION OF THE SOURCE MODULE 
10D, 10E, 14 , 15, AND 20) 



(PHASES 



Translation of the source module 
involves: (1) generating intermediate text 
for the statements in the source module, 
and (2) modifying that intermediate text to 
a form that facilitates the generation of 
the object module. 



and (2) modifies the intermediate text 
entries for I/O statements, computed GO TO 
statements, and RETURN statements. 

Phase 15 primarily transforms the inter- 
mediate text entries for arithmetic expres- 
sions into approximate machine code. That 
is, Phase 15 allows Phase 25 to easily 
generate machine-language instructions for 
arithmetic expressions. 

Phase 20 optimizes the intermediate text 
for subscript expressions. This optimiza- 
tion process increases the efficiency of 
the object module by decreasing the amount 
of computation associated with subscript 
expressions. 



Intermediate Text Generation (Phases 10D 
and 10E) 



OBJECT MODULE GENERATION (PHASES 12, 14, 
20, 25, AND 30) 



Intermediate text is an internal rep- 
resentation of the source statements from 
which the machine-language instructions of 
the object module are produced. In gener- 
al, intermediate text is generated by scan- 
ning the source statements from left-to- 
right and by constructing one-word 
intermediate text entries for the source 
text contained in those statements. 
(Special intermediate text is generated 
for: (1) COMMON, EQUIVALENCE, FORMAT, READ, 
WRITE, and FIND statements; and (2) sub- 
scripted variables . ) 

As intermediate text is generated, 
entries are made in the dictionary and/or 
overflow table for the variables, con- 
stants, arrays, statement numbers, sub- 
scripts, etc. , that appear in the source 
statements. The information contained in 
the dictionary and overflow table entries 
supplements the intermediate text in the 
generation of ma chine- language instruc- 
tions. The intermediate text entries are 
associated with the dictionary and overflow 
table entries by pointers that reside in 
the text entries. 



Intermediate Text Modification (Phases 14, 
15, and 20) 



Phases 14, 15, and 20 modify the inter- 
mediate text produced by Phases 10D and 
10E. The main purpose of this modification 
is to transform the intermediate text to a 
format that facilitates the generation of 
machine-language instructions by Phase 25. 

Phase 14: (1) replaces the pointers to 
the dictionary in the intermediate text 
entries with information contained in the 
dictionary entries (e.g., the relative 
addresses that are assigned by Phase 12) ; 



An object module consists of control 
dictionaries (external symbol dictionary 
and relocation dictionary) , text, and an 
END statement. The external symbol dic- 
tionary (ESD) contains the external symbols 
that are defined or referred to in the 
module. The relocation dictionary (RLD) 
contains information about address con- 
stants in the object module. (An address 
constant designates the relative storage 
address into which the address of a rou- 
tine, library subprogram, or symbol is to 
be relocated.) The text (TXT) contains the 
instructions and data of the object module. 
The END statement indicates the end of the 
object module. 

The object module is not constructed in 
its entirety by any one phase; it is 
constructed throughout the compilation and 
is placed onto the SYSLIN and/or SYSPUNCH 
data sets. Figure 2, the overall compiler 
input/output flow, indicates what each 
phase contributes to the generation of the 
object module. 

Several tables are used by the object 
module during the execution of the instruc- 
tions generated by Phase 25. They are: 

• The branch list table for referenced 
statement numbers (constructed by Phas- 
es 12, 25, and 30) . 

• The branch list table for statement 
function expansions and DO statements 
(constructed by Phases 14, 20, 25, and 
30) . 

• The base value table (constructed 
throughout the compilation as new base 
registers are required) . 

• The argument list table (constructed by 
Phase 20) . 
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Note: The linkage editor must combine 
certain FORTRAN library subprograms with 
the object module in order to form an 
executable load module. Each library sub- 
program that is externally referenced by 
the object module is included in the load 
module by the linkage editor. Among the 
library subprograms that may be so ref- 
erenced are: 



IHCFCOME 
IHCFIOSH 
IHCDIOSE 



IHCFCOME performs object-time implemen- 
tation of the following FORTRAN statements. 



I/O, or IHCDIOSE for direct access I/O) . 
The FORTRAN I/O interface interprets these 
requests and, in turn, submits them to the 
appropriate BSAM or BDAM routines for 
execution. 



STORAGE MAP GENERATION (PHASES 12, 20, 
AND 25) 



If the MAP option is in effect, the 
compiler generates a storage map on the 
SYSPRINT data set. The storage map is 
generated by Phases 12, 20, and 25. 



• READ, WRITE, and FIND 

• BACKSPACE, REWIND, and ENDFILE 

• STOP and PAUSE 



In addition, IHCFCOME converts input and 
output data into the formats indicated in 
the FORMAT statements. IHCFCOME also proc- 
esses object-time errors and arithmetic- 
type program interruptions and terminates 
the execution of the load module when 
appropriate. 



IHCFCOME does not actually perform the 
reading from and writing onto data sets; it 
submits requests for such operations to the 
appropriate FORTRAN I/O data management 
interface (IHCFIOSH for sequential access 



Phase 12 produces a map of all the 
relative addresses that it assigns. Phase 
20 produces a map of the literals it 
generates and the external references made 
by the source module. Phase 25 produces a 
map of all referenced statement numbers 
within the source module. 



DIAGNOSTIC MESSAGE GENERATION (PHASE 30) 



The various phases of the compiler may 
detect errors in the source module. These 
errors are indicated in the form of special 
intermediate text entries. These text 
entries are examined by Phase 30 and the 
corresponding error messages are generated. 
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Chart 00. Overall Compiler Control Flow 
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Table 1. Compiler Components and Their Major Functions 

■t 



Component and 
Symbolic Name 



Major Functions 



Phase 1 
initial entry 
(IEJFAAAO) 



Processes compiler options, and initiates first compilation. 



Phase 1 
subsequent 
entries 
(IEJFAABO) 



Initiates next compilation in the case of a batch of compilations, 
restarts a compilation, or terminates execution of the compiler. 



Interface 
module 
(IEJFAGAO) 



Processes compiler I/O requests, patch requests, and print control 
operations for all compilations, and end-of -phase/interlude re- 
quests for SPACE compilations; and contains communication area, 
DCBs and DECBs for the compiler data sets, and two I/O suffers that 
are used for the SYSIN and SYSPRINT data sets. 



Performance 

module 

(IEJFAPAO) 



Reduces compilation time; deblocks compiler input and blocks 
compiler output if blocking is specified; manipulates text buffer 
chains for SYSUT1 and SYSUT2, processes end-of -phase requests for 
PRFRM compilations; and contains blocking table, BLDL table, and 
reset table. 



Phase 5 
(IEJFCAAO) 



Obtains and allocates main storage for resident tables and internal 
text buffers, allocates main storage to special I/O buffers to be 
used by the block/deblock routine of the performance module, 
constructs text buffer chains for SYSUT1 and SYSUT2 if the PRFRM 
option is in effect, constructs SEGMAL and the patch table, and 
enters information into the blocking table and the BLDL table. 



Phase 7 
(IEJFEAAO) 



Initializes the communication area and those portions of the dic- 
tionary and overflow table that are independent of the source 
module being compiled, prints heading, and, if necessary, deletes 
Phase 5 from main storage. 



Phase 8 
(IEJFFAAO) 



Converts source modules written with embedded blanks and keywords 
used as variables, arrays, or external names into a format that is 
acceptable as input to Phases 10D and 10E. 



Phase 10D 
(IEJFGAAO) 



Converts COMMON, EQUIVALENCE, FORMAT, DEFINE FILE, SUBROUTINE, 
FUNCTION, and specification statements into intermediate text; and 
creates dictionary and overflow table entries. 



Phase 10E 
(IEJFJAAO) 



Converts statement function definitions, executable statements, and 
interspersed FORMAT statements into intermediate text; and creates 
dictionary and overflow table entries. 



Interlude 10E 
(IEJFJGAO) 



Closes all open data control blocks, and then opens only those for 
the data sets that are required by Phases 12 and 14. 



Phase 12 
(IEJFLAAO) 



Assigns relative address to variables and arrays in COMMON, varia- 
bles and arrays not in COMMON, equated variables, variables in 
subscript expressions, and constants; allocates storage for the 
branch list table for referenced statement numbers; and generates 
part of the object module. 



Phase 1H 
(IEJFNAAO) 



Replaces pointers to dictionary entries with information obtained 
from the dictionary; processes intermediate text for FORMAT, READ, 
WRITE, and FIND statements, assigns a relative position in the 
branch list table for statement function expansions and DO state- 
ments for each statement function encountered; generates part of 
the object module; and frees the main storage occupied by the 
dictionary if the SPACE option is in effect. 
j 

(Continued) 
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Table 1. Compiler Components and Their Major Functions (Continued) 

r t 

Component and 

Symbolic Name j Major Functions 



Interlude 11 
(IEJFNGAO) 



Closes all open data control blocks and then opens only those for 
the data sets that are required by Phase 15 , thereby providing 
additional main storage for Phase 15. 



H 



Phase 15 
(IEJFPAAO) 



Transforms arithmetic expressions into approximate machine code, 
reorders intermediate text for DEFINE FILE statements, and assigns 
registers when required. 



Interlude 15 
(IEJFPGAO) 



Closes all open data control blocks and then opens only those re- 
quired by the compiler for the remainder of this compilation. 



Phase 20 
(IEJFRAAO) 



Optimizes subscript expressions, creates argument list table, and 
generates part of the object module. 



Phase 25 
(IEJFVAAO) 



Transforms intermediate text into machine- language instructions 
(part df the object module) ; and completes the assembly of the 
branch list table for referenced statement numbers, the branch list 
table for statement function expansions and DO statements, and the 
base value table. 



Source symbol 

module 

(IEJFAXAO) 



Used by Phase 12 to contain the names of all variables and con- 
stants used in the source module and their corresponding relative 
addresses. 



Object listing 

module 

(IEJFVCAO) 



Used by Phase 25 in conjunction with 
generate the object listing module. 



the source symbol module to 



Phase 30 
(IEJFXAAO) 



Generates error and warning messages if any from intermediate 
text, processes the END statement, and generates the final part of 
the object module. 



Section 1; 
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SECTION 2: DISCUSSION OF COMPILER PHASES 



Section 2 describes the logic and 
tions of each phase of the compiler. 



PHASE 1 (IEJFAAAO/IEJFAABO) 



func- 



Loading the performance module if the 
PRFRM option is in effect and if the 
SIZE option is at least 18504. 
Opening required data control blocks. 
Loading Phase 5. 



Phase 1 is both the first and last phase 
to be executed for each compilation. The 
phase is initially entered from the calling 
program via a supervisor- as sis ted linkage; 
subsequent entries are made from either 
Phase 5 if a PRFRM compilation is altered 
to a SPACE compilation (restart condition) , 
or from Phase 30 — the last processing 
phase of the compiler. In addition, if a 
permanent I/O error occurs. Phase 1 is 
entered from the phase that requested the 
I/O operation. If an I/O error has 
occurred. Phase 1 returns control to the 
calling program and the compilation is 
terminated. 

At the initial entry (IEJFAAAO), Phase 1 
initiates the first compilation and then 
transfers control to Phase 5. 

At subsequent entries (IEJFAABO) , Phase 
1 either initiates the next compilation if 
other source modules are to be compiled, or 
terminates the compilation (i.e., if no 
more source modules are present, or if a 
permanent I/O error has occurred) . If a 
new compilation is initiated. Phase 1 
transfers control to the next phase (Phase 
5 for SPACE compilations, or Phase 7 for 
PRFRM compilations). If the compilation is 
terminated. Phase 1 returns control to the 
calling program with the appropriate return 
code. 



Chart 10 illustrates the overall logic 
and the relationship among the routines 
used in Phase 1. Table 2, the routine 
directory, lists the routines used in the 
phase and their functions. 



INITIAL ENTRY 



At the initial entry. Phase 1 initiates 
the first compilation. This entails : 

• Loading the interface module. 

• Processing compiler options and new 
DDNAMES . 

• Loading the source symbol module if the 
object listing option is in effect. 



Loading the Interface Module 



When Phase 1 receives control from the 
calling program, it loads the interface 
module (IEJFAGAO) into main storage via the 
LOAD macro-instruction. The interface 
module contains : 

• The communication area (FCOMM). 

• DCBs (data control blocks) and DECBs 

(data event control blocks). 

• Interface routines. 

• Two I/O buffers. 

COMMUNICATION AREA: The communication area 
contains the following type of information: 



• User-specified 
(e.g., DECK). 



options and parameters 



• Default values for compiler options. 
The interface module is assembled, and 
processed by the linkage editor during 
system generation. This allows the 
user to specify default values for 
compiler options (refer to the publica- 
tion IBM System/360 Operating System: 
System Generation ) . These default 
values will be assumed if the corres- 
ponding values in the PARM field of the 
EXEC statement are not included by the 
user. (Refer to Appendix B for the 
options for which default values may be 
specified during the system generation 
process. ) 

• Information required for communication 
between the compiler and the operating 
system, such as: 

1. Branch instructions to specific 
routines in the interface module. 
(For PRFRM compilations, these 
branch instructions are, in effect, 
replaced by branch instructions to 
routines in the performance 
module. ) 

2. A pointer to DCBs (data control 
blocks) and the DECBs (data event 
control blocks) needed for 
input/output operations during the 
compilation. 
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• Compilation information, such as: 

1. Type of program/subprogram being 
compiled (i.e., main program, FUNC- 
TION subprogram, or SUBROUTINE 
subprogram) . 

2. Sizes of the internal text buffers. 

3. Addresses of internal text buffers, 
table indexes, and work areas. If 
the PRFRM option is in effect, the 
communication area contains the 
address of the first text buffer in 
each of the text buffer chains that 
are constructed by Phase 5. 

4. Indicators (e.g., indicators of any 
errors encountered during the 
compilation) . 

• Object-time information, such as: 

1. Size of COMMON to be used with the 
object module, and of the tables 
required for the object module exe- 
cution. 

2. The location counter used, through- 
out the compilation, for the 
assignment of object-time address- 
es. 



DCBS AND DECBS: The DCBs and DECBs for the 
data sets used during the compilation are 
assembled into the interface module in 
skeletal form. (For a description of the 
DCBs and DECBs refer to the publication IBM 
System/360 Operating System: Introduction 
to Control Program Logic, Program Logic 
Manual . ) Some fields of the DCBs are 
filled in by the control program when the 
data control blocks are opened (refer to 
the publication IBM System/360 Operating 
System: Concepts and Facilities ). However, 
the DCB block size fields for data sets 
SYSUTl and SYSUT2 are overlayed with values 
computed by the compiler. In addition, if 
the DCB block sizes for the other data sets 
are not specified in DD statements, stand- 
ard default values are assumed. They are: 

• 80 for SYSIN, SYSLIN, and SYSPUNCH. 

• 121 for SYSPRINT. 



INTERFACE ROUTINES : The interface module 
contains four interface routines: an I/O 
routine, an end-of-phase routine, a print 
control operations routine, and a patch 
routine (refer to Chart 11) . 

The I/O routine (SIORTN) processes I/O 
requests of the compiler. For SPACE compi- 
lations, the I/O requests are initiated via 
a linkage to this routine. (Refer to 
Appendix C for a description of this lin- 



kage to the interface module.) For PRFRM 
compilations, the I/O requests are initiat- 
ed via a linkage to the PIORTN routine in 
the performance module. The PIORTN, in 
turn, links to the SIORTN routine in the 
interface module. The SIORTN routine: 

• Analyzes the linkage parameters passed 
to it by either the component of the 
compiler requesting I/O, or by other 
interface routines. These parameters 
indicate: (1) the type of request 
(read, write, or check) , (2) the 
address of the I/O buffer for the 
operation, and (3) what data set is to 
be used for the operation. 

• Fulfills the request by issuing the 
appropriate macro-instruction (READ, 
WRITE, and/or CHECK). 

The compile-time I/O error recovery pro- 
cedure is illustrated in Chart 11. 



The end-of-phase routine (SNEXT) is used 
to pass control from one component of the 
compiler to the next for SPACE compila- 
tions. The transferring of control between 
compiler components is initiated via a 
linkage to this routine. (Refer to Appen- 
dix C for a description of this linkage to 
the interface module. ) The end-of-phase 
routine: 

• Analyzes the linkage parameters passed 
to it by the component of the compiler 
relinquishing control. These paramet- 
ers indicate the name of the next 
component to be executed and the dispo- 
sition of various data sets. 

• Logically repositions the data sets 
indicated in the linkage parameters via 
the CLOSE, type=T, macro-instruction. 

• Transfers control to the next component 
via the XCTL macro-instruction. 

The print control operations (PRTCTRL) 
routine allows the use of immediate-type 
control operations for the SYSPRINT data 
set. If the data set is being placed onto 
an intermediate storage device before being 
printed, the printer control codes remain 
as part of the data set (thereby retaining 
device independence) . 

The patch routine (PATCH) allows tem- 
porary modification of the compiler 
modules. (A module is modified for the 
duration of a batch compilation.) Each 
compiler module unconditionally branches to 
the patch routine to check whether the 
module being executed is to be modified. 
(Refer to Appendix C for a description of 
this linkage to the interface module.) If 
it is, the patch routine overlays the 
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instructions or data of the module to be 
modified with patch information for that 
module. This information is placed in the 
patch table (a 100-byte portion of the 
patch routine) by Phase 5. If there is no 
patch information, control is immediately 
returned to the module being executed. 

I/O BUFFERS; The two I/O buffers are used 
for the SYS IN and SYSPRINT data sets. 
SYSIN uses the I/O buffers during source 
statement adjustment (if required), or 
source statement scanning. The card images 
of the source module to be compiled are 
alternately read into one of the two buf- 
fers. The double-buffer scheme allows for 
overlapping the processing of a card image 
in one buffer with the reading of the next 
card image of the source module into the 
other buffer. 

SYSPRINT uses the I/O buffers for: (1) 
writing patch records and compiler informa- 
tion messages, (2) listing the source 
module, and (3) generating the storage map. 



Processing Compiler Options and New DDNAMES 



Options may be chosen by the user to 
tailor the output of the compiler to his 
specifications. This information is speci- 
fied in the EXEC statement and is entered 
into an area designated by the calling 
program. The contents of this area are 
obtained by Phase 1 via an address in 
general register 1. They are then encoded 
and entered in the communication area. For 
a description of the options and their use, 
refer to the publication IBM System/360 

Operating System; FORTRAN IV (E) 

Programmer's Guide . 

If the compiler is invoked via the LINK 
or ATTACH macro- instruction, the user may 
change the DDNAMES of the compiler data 
sets. The substitute DDNAMES are obtained 
by Phase 1 via an address in general 
register 1. 



Loading the Source Symbol Module 



If the object listing facility of the 
compiler has been enabled. Phase 1 checks 
whether the object listing option (a $ in 
the PARM field of the EXEC statement) is 
specified. (The object listing facility is 
enabled by reassembling Phase 1 with the 
branch instruction that disables the facil- 
ity either removed or replaced with a no-op 
instruction. ) If the option is specified. 
Phase 1: (1) sets the appropriate indicator 
in the communication area, and (2) loads 



the source symbol load module (SORSYM) into 
main storage. SORSYM, a SYS1.LINKLIB load 
module (IEJFAXAO), reserves an area in main 
storage. The names of all variables and 
constants used in the source module and 
their corresponding relative addresses are 
placed into this area by Phase 12. When 
the area (3,200 bytes) is full, all subse- 
quent variables and constants are omitted 
from the object module listing. 

If the object listing option is speci- 
fied, but the object listing facility has 
not been enabled. Phase 1 indicates an 
invalid compiler option, by setting the 
invalid option bit in the communication 
area. 



Loading the Performance Module 



Phase 1 examines the PRFRM bit in the 
communication area to determine if the 
PRFRM option is in effect. If the PRFRM 
option is specified, and if the SIZE option 
is at least 18504, Phase 1 loads the 
performance module (IEJFAPAO) into main 
storage. The performance module allows 
more efficient I/O operations (via fewer 
OPENs, blocking, and chaining) , and reduces 
phase-to- phase transition processing there- 
by decreasing compilation time. The per- 
formance module is composed of two routines 
and three tables. 



PERFORMANCE MODULE ROUTINES ; The perfor- 
mance module contains an I/O routine, and 
an end-of-phase routine (refer to Charts 12 
and 13) . 

The I/O routine (PIORTN) is used to 
deblock compiler input on SYSIN; and to 
block compiler output on SYSLIN, SYSPRINT, 
and SYSPUNCH, as required by the block 
sizes specified for the above data sets. 
In addition, if the ADJUST option is in 
effect, the I/O routine is used to block 
the output of Phase 8 on the SYSUT2 data 
set. The I/O routine also manipulates the 
text buffer chains for the SYSUT1 and 
SYSUT2 data sets (refer to the Phase 5 
section "Constructing Text Buffer Chains 
for PRFRM Compilations"). 

I/O requests for a PRFRM compilation are 
initiated via a linkage to this routine. 
(Refer to Appendix C for a description of 
this linkage to the performance module.) 
The I/O routine: 



• Analyzes the linkage parameters passed 
to it by the calling phase. These 
parameters indicate: (1) the type of 
request (read, write, check, or flush) , 
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(2) the address of the area into which, 
or from which the logical record is to 
be moved, and (3) the data set to be 
used for the operation. (A flush 
request forces the contents of the 
current output buffer to be written 
out.) 

• Deblocks compiler input from SYSIN if a 
blocking factor greater than 1 is spec- 
ified. The PIORTN routine reads (via a 
linkage to the SIORTN routine in the 
interface module) a block from the 
SYSIN data set into an I/O buffer only 
when an entire block has been deblocked 
and moved into the area requested by 
the calling phase. This reduces the 
number of READ macro- instruct ions 
issued for a compilation and thus 
decreases compilation time. 

• Blocks compiler output on the output 
data sets if their corresponding block- 
ing factors are greater than 1. (Each 
blocking factor is determined from the 
BLKSIZE (block size) field in the DCB 
parameter of the associated DD state- 
ment.) In general, the PIORTN writes 

(via a linkage to the SIORTN routine in 
the interface module) a block onto an 
output data set only when the I/O 
buffer containing that block has been 
filled. (However, when a flush opera- 
tion is requested, the PIORTN will 
force a truncated buffer to be written 
if the buffer is partially filled. ) 
This reduces the number of WRITE macro- 
instructions issued for a compilation 
and thus decreases compilation time. 



The end-of -phase routine (PNEXT) is used 
to pass control from one component of the 
compiler to the next for PRFRM 
compilations. The transferring of control 
between compiler components is initiated 
via a linkage to this routine. (Refer to 
Appendix C for a description of this lin- 
kage to the performance module.) The end- 
of- phase routine: 

• Analyzes the linkage parameters passed 
to it by the component of the compiler 
relinquishing control. These 
parameters indicate the name of the 
next component to be executed, and the 
disposition of the various data sets. 

• Logically repositions the data sets 
indicated in the linkage parameters via 
the CLOSE, type=T, macro-instruction. 
Various pointers and indicators in the 
communication area, the performance 
module, and the blocking table are also 
reset at this time for the repositioned 
data sets (refer to the Phase 5 section 
"Constructing Text Buffer Chains for 
PRFRM Compi lati ons " ) . 



• Transfers control to the next component 
via the XCTL macro-instruction. (If 
the next component is an interlude, the 
performance module bypasses the execu- 
tion of the interlude and transfers 
control to the next phase of the com- 
piler. ) 



PERFORMANCE MODULE TABLES: The performance 
module contains three tables : the blocking 
table, the BLDL table, and the reset table. 



Phase 5 constructs a blocking table 
entry for each of the data control blocks 
that are opened by Phase 1. The blocking 
table provides the PIORTN routine with the 
information necessary to deblock compiler 
input, and to block compiler output. 
(Refer to Appendix H for the format of the 
blocking table.) 



Phase 5 constructs the BLDL table via 
the BLDL macro-instruction. The BLDL table 
provides the PNEXT routine with the infor- 
mation necessary to transfer control from 
one component of the compiler to the next 
with more efficiency than is possible on a 
SPACE run. (Refer to Appendix H for the 
format of the BLDL table. ) 



The reset table (RESETABL) is used by 
the PNEXT routine to determine which, if 
any, of the record counts for the chained- 
buffer data sets (SYSUTl and SYSUT2) must 
be reset. The record count of the data set 
that is to be used for output by the next 
phase is always reset. Resetting the 
record count is necessary in order to 
determine whether actual READs are required 
for that data set when it is used as input 
by a subsequent phase. (Refer to Appendix 
H for a description of the format and use 
of the reset table.) 



Opening Required Data Control Blocks 



The data control blocks that are opened 
by Phase 1 depends upon the options speci- 
fied by the user. 



If the SPACE option is in effect, or if 
the SIZE option is less than 18504, Phase 1 
opens, via the OPEN macro-instruction, only 
the data control blocks for the data sets 
used by Phases 5, 7, 10D, and 10E (SYSIN, 
SYSUTl, and SYSPRINT) . (In addition, if 
the ADJUST option is in effect, Phase 1 
opens the data control block for SYSUT2. 
SYSUT2 is used to contain the output of 
Phase 8.) The main storage that is saved 
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at this time by not opening the data 
control blocks for SYSLIN SYSPUNCH, and 
SYSUT2 (if the ADJUST option is not in 
effect) is necessary for the execution of 
Phases 10D and 10E. (The SYSLIN and SYS- 
PUNCH data sets are not needed by the 
compiler until the execution of Phase 12. 
Therefore, their corresponding data control 
blocks are not opened until the execution 
of Interlude 10E. ) 



If the PRFRM option is in effect, and if 
the SIZE option is at least 18504, Phase 1 
opens (via the OPEN macro-instruction) the 
data control blocks for all the data sets 
required by the compiler. Because all the 
required data control blocks are opened 
initially, the compiler can bypass the 
execution of Interludes 10E, 1H, and 15; 
and can avoid repeated closing and re- 
opening of data control blocks. Bypassing 
the execution of the interludes reduces 
phase-to-phase transition time and thus 
decreases compilation time. 

The manipulation of data control blocks 
by subsequent components of the compiler 
for SPACE compilations as well as for PRFRM 
compilations is illustrated in Appendix D. 



Loading Phase 5 



Phase 5 (IEJFCAAO) is loaded into main 
storage by Phase 1, using the LOAD macro- 
instruction. This is not the normal 
condition; normally, the XCTL macro- 
instruction in the end-of-phase routine is 
used to call a phase into main storage. 

Phase 1 loads Phase 5 into the highest 
area of available main storage, relative to 
location zero. (The XCTL macro-instruction 
would load Phase 5 into the lowest area of 
available main storage. ) This special 
loading by Phase 1 permits Phase 5 to set 
up the resident tables in the lowest area 
of available main storage. The physical 
locations occupied by the various compiler 
components and resident tables are illus- 
trated in Appendix A. 



(via the OPEN 
data control 
required for 

option is in 



SUBSEQUENT ENTRIES 



At subsequent entries. Phase 1 either: 

• Initiates a new compilation, or 

• Terminates the compilation. 



Initiating a New Compilation 



If a new compilation is to be initiated, 
Phase 1 first determines if a PRFRM or a 
SPACE compilation is to be performed. If a 
PRFRM compilation is to be performed, Phase 
1 immediately transfers control to Phase 7. 

If a SPACE compilation is to be per- 
formed, Phase 1 determines if a restart 
condition exists. That is, if a PRFRM 
compilation was requested and Phase 5 det- 
ermined that the required main storage for 
the PRFRM compilation was not available. 
Phase 5 then alters the PRFRM compilation 
to a SPACE compilation and returns control 
to Phase 1. 

If a restart condition exists. Phase 1: 
(1) deletes (via the DELETE 
macro- instruction) the performance module 
and Phase 5 from main storage, (2) closes 
(via the CLOSE macro-instruction) the data 
control blocks for all required compiler 
data sets (opened by Phase 1 for the PRFRM 
option), and (3) reopens 
macro-instruction) only the 
blocks for the data sets 
Phases 7, 8 (if the ADJUST 
effect) , 10D, and 10E. Phase 1 then loads 
(via the LOAD macro-instruction) Phase 5 
into main storage and transfers control to 
Phase 5. 

If a restart condition does not exist 
and if the SPACE option is in effect. Phase 
1 first frees (via the FREEMAIN 
macro- instruction) the main storage that 
was previously allocated to the compiler 
during execution of Phase 5 for the inter- 
nal text buffers and the overflow table. 
Subsequent Phase 1 processing except for 
the deletion of the performance module and 
Phase 5 is the same as that described for 
the restart condition. 



Terminating the Compilation 



If the last source module on the SYSIN 
data set has been compiled, Phase 1 first 
requests a flush operation for the SYSLIN, 
SYSPUNCH, and SYSPRINT data sets. A flush 
request forces the current output buffer 
being used for a blocked data set to be 
written. This insures that all compiler 
output for blocked data sets is written. 
In the case of an unblocked data set, the 
flush request for that data set is ignored. 
Phase 1 next closes (via the CLOSE 
macro-instruction) the data control blocks 
for all the data sets used by the compiler. 
Phase 1 then: (1) frees (via the FREEMAIN 
macro- instruction) all the main storage 
that was allocated to the compiler during 
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execution of Phase 5 f and (2) deletes (via 
the DELETE macro-instruction) the interface 
module, the performance module for a PRFRM 
compilation, and the source symbol module 
if the object listing option is in effect. 
Control is then returned to the calling 
program with the proper return code. 

If internal errors (e.g., permanent I/O 
errors) occur at any time, the current 
compilation is immediately terminated by 
calling Phase 1. Phase 1 then performs the 
above processing and returns control to the 
calling program with a return code of 16. 



PHASE 5 (IEJFCAAO) 



Phase 5, the second phase of the compil- 
er, is entered after the completion of 
Phase 1. It is executed for each source 
module in a batch SPACE compilation but 
only for the first source module in a batch 
PRFRM compilation. The functions of the 
phase are: 

• Obtaining main storage for the compil- 
er. 

• Allocating main storage to the compil- 
er. 

• Constructing SYSUT1 and SYSUT2 text 
buffer chains if the PRFRM option is in 
effect. 

• Constructing some of the resident 
tables that are used by the compiler. 

Chart 20 illustrates the overall logic 
and the relationship among the routines of 
Phase 5. Table 3, the routine directory, 
lists the routines used in the phase and 
their functions. 



• The interface module. 

• The performance module if loaded. 

• BSAM routines. 

• Phase 5. 

Phase 5, upon receiving control from 
Phase 1, calculates tne total amount of 
main storage obtained by Phase 1, and 
subtracts this amount from the value of the 
SIZE option. (If the SIZE option was not 
specified by the user, the minimum amount 
required for a SPACE compilation is assumed 
as a default value for the SIZE, option.) 
The result of this calculation is the 
amount of main storage that Phase 5 
attempts to obtain via the GETMAIN macro- 
instruction. If more than this amount is 
obtained, Phase 5 frees the excess via the 
FREEMAIN macro-instruction. 

If less than the minimum amount required 
for a SPACE compilation is obtained, a 
GETMAIN (mode=U) macro-instruction is 
issued to obtain the minimum amount. 

If less than the minimum amount required 
for a PRFRM compilation is obtained, the 
compilation is either terminated if block- 
ing was requested, or restarted (altered to 
a SPACE compilation) if blocking was not 
requested. 



ALLOCATING MAIN STORAGE 



The procedure used by Phase 5 for allo- 
cating main storage depends on whether a 
SPACE or a PRFRM compilation has been 
initiated. Appendix A illustrates the main 
storage allocated to the compiler for both 
SPACE and PRFRM compilations. 



At the conclusion of Phase 5 processing, 
control is passed either to Phase 1 (to 
restart or terminate the compilation) , or 
to Phase 7. 



OBTAINING MAIN STORAGE 



The amount of main storage required by 
the compiler depends on whether a SPACE or 
a PRFRM compilation is being performed. 
For a SPACE compilation, a minimum of 
15,360 bytes is required. For a PRFRM 
compilation, a minimum of approximately 
19,500 bytes is required. (The exact 
amount depends on the device configuration 
of the user. That is, different I/O devi- 
ces require different access method rou- 
tines and different control blocks.) 

The process of obtaining main storage is 
actually started in Phase 1. Phase 1 has 
already obtained main storage for: 



For SPACE Compilation; 



For a SPACE compilation, the main stor- 
age obtained by Phase 5 is allocated, via 
the storage allocation table, among a tran- 
sient work area required by the control 
program (952 bytes for SPACE runs; 1800 
bytes for PRFRM runs) , the dictionary, the 
overflow table, four internal text buffers, 
and padding for Phase 10E. The storage 
allocation table (refer to Appendix I) 
indicates the amount of main storage to be 
allocated to the internal text buffers, and 
the dictionary and overflow table. 

The main storage allocated to the dic- 
tionary and overflow table, except for the 
reserved word portion of the dictionary, 
may be segmented. That is, tne dictionary 
and overflow table may occupy more than one 
segment of main storage. The location of 
the segments allocated to the dictionary 
and overflow table are recorded 
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(sequentially by address) in a segment 
address list (SEGMAL) . SEGMAL resides at 
the beginning of the first segment. The 
FOVFLNDX field in the communication area is 
initialized to point to the beginning loca- 
tion of the overflow index, which is also 
the location immediately following the last 
entry in SEGMAL. (Phase 5 initializes 
FOVFLNDX although the actual loading into 
main storage of the overflow index occurs 
in Phase 7.) 

The dictionary portions reside in the 
highest storage segment (s) relative to 
location and the overflow table portions 
reside in the lowest storage segment(s). 
This ensures that the dictionary resides 
"above" the overflow table. The dictionary 
must reside above the overflow table 
because the storage allocated to the dic- 
tionary is freed (via the FREEMAIN 
macro- instruct ion) for SPACE compilations 
at the conclusion of Phase 14 processing. 
This additional main storage is required 
for the execution of subsequent phases, 
primarily for Phase 15 (refer to Appendix 
A). (For PRFRM compilations, the main 
storage allocated to the dictionary is not 
freed until compilation is terminated by 
Phase 1.) 

The main storage allocated to the inter- 
nal text buffers may be segmented. Howev- 
er, the main storage for each buffer itself 
must be contiguous. The location of the 
segment assigned to each buffer is indicat- 
ed in the communication area. 



sient work area, the dictionary and over- 
flow table, the four internal text buffers, 
and padding for Phase 15. If there is 
sufficient storage, subsequent main storage 
allocation for a PRFRM compilation with 
blocked I/O is the same as that described 
for a SPACE compilation except for the 
construction of internal text buffer 
chains. 

If the remaining main storage is not 
sufficient, the compilation is terminated 
and control is transferred to Phase 1. 
Phase 1, in turn, passes control to the 
calling program to terminate the compila- 
tion. 

UNBLOCKED I/O ; If all I/O is unblocked, 
Phase 5 determines if the amount of main 
storage obtained is sufficient for the 
transient work area, the dictionary and 
overflow table, and the four internal text 
buffers. If there is sufficient storage, 
subsequent main storage allocation for a 
PRFRM compilation with unblocked I/O is the 
same as that described for a SPACE compila- 
tion except for the construction of inter- 
nal text buffer chains. 

If the amount of main storage obtained 
is not sufficient, Phase 5 first frees (via 
the FREEMAIN macro-instruction) all the 
main storage it obtained. Phase 5 then 
alters the PRFRM compilation to a SPACE 
compilation (restart condition) and trans- 
fers control to Phase 1. Phase 1 then 
initializes the compiler for a SPACE compi- 
lation. 



For PRFRM Compilations 



For a PRFRM compilation, the main stor- 
age allocation algorithm must determine if 
blocked I/O is specified by the user. 

BLOCKED I/O: If any blocked I/O is speci- 
fied, portions of the obtained main storage 
must be allocated to special I/O buffers 
required for blocking and deblocking. 
Phase 5 allocates main storage for two I/O 
buffers for each data set for which block- 
ing is requested. The size of each buffer 
is determined by the BLKSIZE field in the 
DCB parameter of the associated DD state- 
ment. If the BLKSIZE fields are not speci- 
fied, the compiler assumes the following 
default values for the compiler data sets: 

• SYSPRINT — 121. 

• SYSIN, SYSLIN, and SYSPUNCH — 80. 

• The block sizes for SYSUT1 and SYSUT2 
are determined dynamically by the com- 
piler. 

After allocating main storage for the 
special I/O buffers. Phase 5 determines if 
sufficient storage remains for the tran- 



CONSTRUCTING TEXT BUFFER CHAINS FOR PRFRM 
COMPILATIONS 



After main storage has been allocated to 
the transient work area, the dictionary and 
the overflow table, the four internal text 
buffers, and any required I/O buffers for 
blocking. Phase 5 uses as much of the 
remaining main storage as possible (up to 
the value of the SIZE option) by construct- 
ing text buffer chains. 

The text buffer chains are used when 
reading from or writing onto the intermedi- 
ate text work data sets (SYSUT1 ana 
SYSUT2). Two text buffer chains are con- 
structed for both the SYSUT1 and SYSUT2 
data sets. One of the four internal text 
buffers, already allocated by Phase 5, 
(referred to as the I/O text buffers) is 
then chained in as the last buffer in each 
of the text buffer chains. Only the I/O 
text buffers are ever read into or written 
from. The intermediate text in the remain- 
ing buffers (referred to as non-I/O text 
buffers) is retained in main storage. 
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The maximum number of buffers in each 
chain is a function of the number of 
segments into which the remaining main 
storage is divided. The minimum size of 
each I/O buffer is 96 bytes; the maximum 
size is 1,696 bytes. The minimum size of 
each non-1/0 buffer is 16 bytes; the maxi- 
mum size is 32,760 bytes. 

Each buffer in a chain (including the 
I/O text buffer) is preceded by an eight- 
byte control area. Each control area 
contains: (1) a chain address field (four 
bytes) , and (2) a length field (four 
bytes) . 

Figure 3 illustrates a text buffer chain 
that contains N buffers. 

Because only the last buffer in each of 
the two chains associated with a particular 
data set is used as an I/O buffer, a 
portion of the SYSUT1 or SYSUT2 data sets 



resides in main storage. For example, 
consider the case in which SYSUT1 is used 
to contain the intermediate text input to a 
phase and SYSUT2 is used to contain the 
intermediate text output of a phase. Since 
part of the SYSUTl data set resides in main 
storage (i.e., buffers 1 through N-l in the 
two chains constructed for SYSUTl , where 
each chain contains N buffers) , the phase 
being executed requires fewer read opera- 
tions. 

In addition, a portion of the output 
data set (SYSUT2) will reside in main 
storage (i.e., buffers 1 through N-l in the 
two chains constructed for SYSUT2, where 
each chain contains N buffers). Therefore, 
the phase being executed requires fewer 
write operations. As a result of retaining 
portions of SYSUTl and SYSUT2 in main 
storage, overall compiler efficiency is 
increased because of a decrease in I/O 
activity. 
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BFR N 
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t 4 

FTXTBFXX is one of the four communication area fields that point to the initial buffer 
in each of the four chains. That is, FTXTBFA1 points to the first buffer in the first 
buffer chain for SYSUTl; FTXTBFA2 points to the first buffer in the second buffer 
chain for SYSUTl; FTXTBFB1 points to the first buffer in the first buffer chain for 
SYSUT2; and FTXTBFB2 points to the first buffer in the second buffer chain for SYSUT2. 

Buffers 1 through N-l point to the next buffer in the chain. Buffer N, the last 
buffer, points to itself. 

L(BFR 1), L(BFR 2) ,..., and L(BFR N) contain the lengths of the buffers in the chain. 

L 

Figure 3. Text Buffer Chain Format 
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The buffers in each of the two chains 
constructed for a particular data set are 
used alternately. That is, buffer 1 in 
chain 1, buffer 1 in chain 2, buffer 2 in 
chain 1, buffer 2 in chain 2, etc. For 
example, consider the case in which SYSUT1 
is being used as the output data set. 
Assume that each of the two chains con- 
structed for SYSUT1 contain three buffers. 
Figure 4 shows the order in which the 
buffers are used. (The numbers to the 
right of each buffer indicate the order.) 

FTXTBFA1 is initialized to point to the 
first buffer in chain 1; FTXTBFA2 is ini- 
tialized to point to the first buffer in 
chain 2. 

The contents of the first two buffers in 
each chain remain in main storage. That 
is, when the phase in control links to the 
PIORTN routine for an output operation 
involving those buffers, the PIORTN routine 
recognizes that neither of these buffers is 
the last buffer in the respective chain. 
The PIORTN routine does not initiate a 
write from these buffers; it inserts the 
address of the next buffer (in the current 
chain) into the FTXTBFA1 field and its size 
into the FTXBFSZA field in the communi- 
cation area, and then returns control to 
the phase. 

The phase then switches the contents of 
the FTXTBFA1 and FTXTBFA2 fields. This 
enables the alternate filling of the buf- 
fers in both chains because the phase 
always requests a write from the address of 
the buffer in the FTXTBFA1 field. 

When the phase requests a write either 
from the last buffer in chain 1, or from 



the last buffer in chain 2, the PIORTN 
routine actually initiates a write opera- 
tion. Because the I/O buffers are also 
used alternately, all write operations from 
this point on are overlapped. (Similarly, 
all read operations are overlapped when the 
first N-l buffers in both chains have been 
used.) After execution of the phase in 
question is completed, control is passed to 
the PNEXT routine in the performance 
module. The PNEXT routine reinitializes: 
(1) the contents of the FTXTBFA1, FTXTBFA2, 
FTXTBFB1, and FTXTBFB2 fields in the com- 
munication area so that they point to the 
first buffer in each chain, and (2) the 
PINITBFS field in the performance module. 
(The FINITBFS field in the communication 
area contains these pointers.) In addi- 
tion, the last two 1-byte fields are reini- 
tialized in the blocking table entry for 
each data set that is TCLOSEd by the PNEXT 
routine. 



Note 1 : A count is kept of the number of 
records actually written on the intermedi- 
ate text output data set (SYSUTl or SYSUT2) 
during the execution of each phase. If 
this count is not greater than two, the 
next phase that uses the output data set as 
input does not read any records because all 
the intermediate text input is in main 
storage. 



Note 2 : 



For 



a PRFRM and ADJUST compila- 
tion, the output from Phase 8 is automat- 
ically blocked on SYSUT2. The I/O text 
buffers (the last buffer in each of the 
buffer chains constructed for SYSUT2) are 
used as the special blocking buffers for 
SYSUT2. The blocking factor for SYSUT2 
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(computed by Phase 5) is the largest inte- 
gral multiple of 80 based on the size of 
the I/O text buffers. Phase 5 inserts the 
blocking factor and the addresses of the 
buffers into the performance module block- 
ing table entry for SYSUT2. 



(100 bytes) in the interface module. Post- 
ing consists of: (1) converting the con- 
tents of a patch record into a format that 
is usable to the patch routine, and (2) 
moving the converted patch record to the 
patch table. When the patch table is full, 
any further patches are ignored and are not 
placed on the SYSPRINT data set. 



CONSTRUCTING RESIDENT TABLES 



The following resident tables of the 
compiler (described in Appendix H) are 
constructed by Phase 5 : 

• The segment address list (SEGMAL) . 

• The patch table. 

• The blocking table and the BLDL table 
(resident only for PRFRM compilations). 

SEGMAL is constructed as main storage 
segments are allocated to the dictionary 
and the overflow table. The patch table, a 
portion of the interface module, is con- 
structed only if the patch facility has 
been enabled and if patch records precede 
the source statements of the source 
module (s) being compiled. The blocking 
table and the BLDL table, portions of the 
performance module, are constructed only 
for PRFRM compilations. 



SEGMAL 



SEGMAL contains the starting and ending 
addresses of each main storage segment 
allocated to the dictionary and the over- 
flow table. The starting address and the 
length of each segment is obtained as a 
result of the GETMAIN macro-instruction. 
Phase 5 then computes the ending address of 
each segment, and enters both the starting 
and ending address for each segment into 
SEGMAL. This sequence of addresses consti- 
tutes SEGMAL. 



Patch Table 



If the patch facility of the compiler 
has been enabled. Phase 5 determines if the 
first record read from SYSIN is a patch 
record. (The patch facility is enabled by 
reassembling Phase 5 with the branch 
instruction that disables the patch facili- 
ty either removed or replaced with a no-op 
instruction. ) If the first record is a 
patch record, it is first listed on 
SYSPRINT and then posted in the patch table 



Blocking Table and BLDL Table 



Phase 5 constructs the blocking table 
and the BLDL table only for PRFRM compila- 
tions. The performance module contains the 
main storage required for these tables. 



Phase 5 constructs a blocking table 
entry for each of the data control blocks 
that were opened by Phase 1. Phase 5 
places information into the blocking table 
that is required for deblocking compiler 
input and blocking compiler output. This 
information includes such things as : logi- 
cal record length, blocking factor, poin- 
ters to the special buffers allocated by 
Phase 5, etc. 



Phase 5 constructs the BLDL table via 
the BLDL macro- instruction. (For a des- 
cription of the BLDL macro- instruction, 
refer to the publication IBM System/360 
Operating System; Data Management .) The 
BLDL table contains the information neces- 
sary to transfer control, more efficiently 
than for a SPACE compilation, from one 
component of the compiler to the next. The 
construction of the BLDL table reduces 
phase-to-phase transition time and thereby 
decreases compilation time. 



PHASE 7 ( IEJFEAAO ) 



Phase 7 is entered either after the 
completion of Phase 1 for PRFRM compila- 
tions other than the first compilation in a 
batch compilation, or after the completion 
of Phase 5 for all other compilations. The 
functions of Phase 7 are: 

• Initializing the dictionary and the 
overflow table. 

• Initializing the communication area. 

• Deleting Phase 5 if loaded. 

In addition, Phase 7 prints the heading for 
each compilation on the SYSPRINT data set. 
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At the conclusion of Phase 7 processing, 
control is passed to Phase 8 if the ADJUST 
option is specified, or to Phase 10D if the 
NOADJUST option is specified. 

Chart 30 illustrates the overall logic 
of Phase 7. 



INITIALIZING THE OVERFLOW TABLE AND THE 
DICTIONARY 



Phase 7 constructs only those portions 
of the dictionary and the overflow table 
that are independent of the source module 
being compiled. In the 
dictionary index and the 
portion are constructed, 
table, the overflow table 
structed. Refer to Appendix H for a dis- 
cussion of the dictionary and the overflow 
table. 



dictionary, the 

reserved word 

In the overflow 

index is con- 



The index for the dictionary and the 
index for the overflow table are used by 
the compiler to enter information into and 
obtain information from the respective 
table. The reserved word portion of the 
dictionary contains all the reserved words 
of the FORTRAN IV (E) language. Both 
indexes and the reserved word portion of 
the dictionary are assembled as a part of 
the Phase 7 load module. 



Overflow Table Index 



Upper 
Storage 



Lower 
Storage 



Dictionary index 



Reserved word portion 
of dictionary 



Dictionary 



Overflow Table 



SEGMAL | Overflow table index 



Figure 5. Relative Main Storage Locations 
Occupied by Dictionary and Over- 
flow Table Elements, and SEGMAL 



Note; The dictionary is built from upper 
storage to lower storage; the overflow 
table is built from lower storage to upper 
storage. If the dictionary and overflow 
table overlap, a message is issued; no new 
entries are made; and compilation contin- 
ues. 



Phase 7 obtains the starting location of 
the overflow table index from the FOVFLNDX 
field in the communication area. The over- 
flow table index is then moved from the 
Phase 7 load module into the appropriate 
location in main storage. 



Dictionary Index and Reserved Word Portion 



INITIALIZING THE COMMUNICATION AREA 



While Phase 7 is initializing the dic- 
tionary and overflow table, various fields 
in the communication area are filled in. 
The fields are: 



Phase 7 examines SEGMAL and determines 
the main storage locations into which the 
dictionary index and the reserved word 
portion of the dictionary are to be placed. 
The dictionary index is placed into the 
highest portion of the last segment allo- 
cated to the dictionary. The reserved word 
portion is placed immediately below the 
start of the dictionary index. 

Figure 5 shows the relative main storage 
locations occupied by the dictionary index, 
the reserved word portion of the dictio- 
nary, the dictionary itself, the overflow 
table, the overflow table index, and 
SEGMAL. 



FOVFLNXT 
FOVFLBLK 
FDICTNDX 
FDICTNXT 
FDICTBLK 



FOVFLNXT is initialized to contain the 
starting address of the overflow table. 

FOVFLBLK is initialized to contain a 
pointer to the location within SEGMAL that 
contains the ending address of the main 
storage segment currently being used for 
the overflow table. (This address is used 
to determine the end of the current over- 
flow table segment. ) 
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FDICTNDX is initialized to contain the 
starting address of the dictionary index. 

FDICTNXT is used to contain the starting 
address of the dictionary (that is, the 
reserved word portion of the dictionary) . 

FDICTBLK is initialized to contain a 
pointer to the location within SEGMAL that 
contains the starting address of the main 
storage segment currently being used for 
the dictionary. (Since the dictionary is 
built from upper storage to lower storage, 
the starting address of each main storage 
segment used for the dictionary is used to 
determine the end of the current segment. ) 



DELETING PHASE 5 IF LOADED 



Before Phase 7 transfers control to the 
next phase to be executed, it first writes 
the heading line on the SYSPRINT data set 
and then determines whether Phase 5 was 
loaded into main storage by Phase 1. Phase 
1 loads Phase 5 into main storage if: (1) a 
SPACE compilation is being performed, or 
(2) the first source module in a batch 
PRFRM compilation is being compiled. If 
Phase 5 is in main storage. Phase 7 deletes 
Phase 5 from storage (via the DELETE 
macro-instruction), and then transfers con- 
trol to the next phase (Phase 8 or Phase 
10D) . 



• Eliminating 
statements . 



embedded blanks in FORTRAN 



• Adding a special character to all FOR- 
TRAN keywords in a source module that 
are used as variables, arrays, or 
external names. 

• Inserting meaningful blanks between 
successive words in FORTRAN statements. 

Phase 8 converts source statements writ- 
ten in the FORTRAN IV (E) language into a 
format that is acceptable to Phases 10D and 
10E. Phases 10D and 10E require that: (1) 
keywords be reserved for compiler use, (2) 
none of the names used in the source module 
contain embedded blanks, and (3) successive 
names within any statement be separated by 
blanks . 

In addition Phase 8 prepares a source 
module listing if the SOURCE option is 
specified by the user. 

Upon completion of Phase 8 processing, 
control is passed to Phase 10D. 

Figure 6 illustrates the data flow with- 
in Phase 8. 

Chart 40 illustrates the overall logic 
and the relationship among the routines of 
Phase 8. Table 4, the routine directory, 
lists the routines used in the phase and 
their functions. 



PHASE 8 (IEJFFAAO) 



Phase 8 is only loaded into main storage 
and executed if the ADJUST option is in 
effect. Phase 8 is entered after the 
completion of Phase 7 processing. The 
functions of the phase are: 



Note: All input and output operations are 
double buffered. This increases overall 
Phase 8 efficiency by overlapping normal 
processing with I/O operations . In addi- 
tion, for a PRFRM and ADJUST compilation, 
the output from Phase 8 is automatically 
blocked on SYSUT2. The blocking factor is 
determined internally by Phase 5 and is 
inserted into the DCB skeleton for SYSUT2. 
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Figure 6. Phase 8 Data Flow 
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ELIMINATING EMBEDDED BLANKS 



Each source statement consists of one or 
more card images. To eliminate the embed- 
ded blanks in those statements, each card 
image is first read into one of the two I/O 
buffers in the interface module. The card 
image is then moved to a primary work area 
where it is scanned for names and delimi- 
ters via the translate and test (TRT) 
instruction. (If the SOURCE option is 
specified by the user, each card image is 
written from the input buffer onto the 
SYSPRINT data set after that card image has 
been moved to the primary work area . ) 

If a statement number defines the state- 
ment in question, it is packed and then 
moved from the primary work area to the 
current output buffer. The portion of the 
card image up to and including the delimi- 
ter that terminates the execution of the 
TRT instruction is packed (i.e., blanks are 
eliminated) and is then moved to an inter- 
mediate work area. The process of packing 
successive segments of each card image is 
repeated for all the card images on the 
SYSIN data set for the source module cur- 
rently being compiled. When the END state- 
ment is encountered. Phase 8 writes on the 
SYSUT2 data set, either the first statement 
of the next subprogram to be compiled, or 
an end-of-file (EOF) if no more input is 
present. 

Note: A special switch is set if the 
statement in question is a FORMAT statement 
so that any blanks in the H and quote 
fields are not eliminated. 

For example, consider the following 
statement as it appears as input to Phase 
8. 

1 F R M A T (1 H ,1 10) 

The output from Phase 8 for this state- 
ment is: 



than an arithmetic statement or a statement 
function. A keyword may also be contained 
in an arithmetic statement or an arithmetic 
expression. (For example, in the statement 
A=FLOAT(l), FLOAT is a keyword.) 

Phase 8 assumes that all FORTRAN state- 
ments are arithmetic statements until det- 
ermined otherwise. Therefore, whenever a 
FORTRAN keyword is encountered, a special 
unprintable character is added to it to 
indicate to Phases 10D and 10E that the 
keyword is possibly being used as a varia- 
ble, array, or external name. This is done 
by inserting the special character between 
the last character of the keyword and the 
next delimiter in the packed segment. 

Further examination of the statement 
indicates whether the keyword is being used 
as a variable, array or external name, or 
as a normal keyword. If the keyword is not 
being used as a variable, array, or exter- 
nal name, the special character is removed 
so that Phase 10D or Phase 10E recognizes 
the normal use as a keyword. The special 
characters are removed prior to moving the 
statement to the current output buffer. 



INSERTING MEANINGFUL BLANKS 



When an entire card image has been 
packed and placed into the intermediate 
work area, it is prepared for output. 
Phases 10D and 10E do not allow blanks to 
be omitted between successive words of a 
statement. Phase 8, prior to writing out 
the packed card image inserts a blank 
between any such words in a source state- 
ment. 

For example, consider the following 
statement after it has been packed by Phase 
8: 

DIMENSIONABC ( 10 ) 



1 FORMATdH ,110) 

The process of adding a special charac- 
ter to all keywords that are used as 
variables occurs at the same time that 
blanks are being eliminated. 



Prior to moving the statement to the 
current output buffer, a blank is inserted 
so that the statement is written out as: 

DIMENSION ABC (10) 



ADDING SPECIAL CHARACTERS 



PHASE 10D (IEJFGAAO) 



After each packed segment of a card 
image is moved to the intermediate work 
area. Phase 8 checks to see if that segment 
contains a keyword. A keyword may be a 
word that begins any permissible FORTRAN 
(IV) E source statement (e.g., READ) other 



Phase 10D is entered either after the 
completion of Phase 7 if the NOADJUST 
option is in effect, or after the comple- 
tion of Phase 8 if the ADJUST option is in 
effect. Phase 10D processes the declara- 
tive statements of the source module, which 
are COMMON, DIMENSION, EQUIVALENCE, 
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INTEGER, REAL, DOUBLE PRECISION, EXTERNAL, 
FORMAT, DEFINE FILE, and SUBROUTINE or 
FUNCTION (if a subprogram is being 
compiled) . 

If the NOADJUST option is specified, the 
input to Phase 10D resides on the SYSIN 
data set. If the ADJUST option is speci- 
fied, the input to Phase 10D resides on the 
SYSUT2 data set. 



phases of the compiler. Phase 10D converts 
the declarative statements; Phase 10E con- 
verts the statement function definitions 
and the executable statements. The result 
of this conversion is intermediate text (an 
internal representation of the source 
statements) , and the dictionary and over- 
flow table that contain detailed informa- 
tion about specific portions of the state- 
ments . 



Declarative statements, other than the 
FORMAT statement, must precede the state- 
ment function definitions and the execut- 
able statements. The executable statements 
are all FORTRAN IV (E) statements other 
than those listed above and statement func- 
tion definitions. 

In processing the declarative state- 
ments. Phase 10D performs the following 
functions: 

• Prepares intermediate text. 

• Constructs dictionary and overflow 
table entries. 

• Prepares the first part of the source 
statement listing if the SOURCE and 
NOADJUST options are in effect. 

Phase 10D and Phase 10E (the next phase 
to be executed) convert each FORTRAN source 
statement into usable input to subsequent 



The information in the dictionary and 
overflow table supplements the intermediate 
text in the generation of code by subse- 
quent phases. This information is asso- 
ciated with the intermediate text entries 
via pointers that reside in the text 
entries . 

When a statement function definition or 
an executable statement is encountered in 
the input stream, control is passed to 
Phase 10E. 

Figure 7 illustrates the data flow with- 
in the phase. 

Chart 50 indicates the overall logic and 
the relationship among the routines of 
Phase 10D. Table 6, the routine directory, 
lists the routines used in the phase and 
their functions. 
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CREATING INTERMEDIATE TEXT FOR DECLARATIVE 
STATEMENTS 



CONSTRUCTING DICTIONARY AND OVERFLOW TABLE 
ENTRIES 



Phase 10D produces intermediate text, 
which is the form in which information is 
transmitted from the source module to the 
processing phases. (Refer to Appendix E 
for a description of the source statement 
scan required for intermediate text prepar- 
ation. ) 

Intermediate text is prepared for FOR- 
MAT, DEFINE FILE, FUNCTION, and SUBROUTINE 
declarative statements. (Refer to Appendix 
F for the intermediate text format.) This 
text is used to transmit these statements 
to Phases 14, 15, 20, and 25. 

In addition to creating intermediate 
text for DEFINE FILE statements. Phase 10D 
makes the following validity checks for the 
statements. 

• To see that the unit numbers (i.e., 
data set reference numbers) defined in 
the statements do not exceed 99, and 
that the unit numbers are not multiply 
defined. 

• To see that the maximum number of 
records per defined unit does not 
exceed 2 a *». 



Dictionary and overflow table entries 
are made during Phase 10D for: 

• Symbols appearing within declarative 
statements . 

• Statement numbers associated with de- 
clarative statements. 



Entries are made to the dictionary 
(refer to Appendix H) for symbols appearing 
in all declarative statements except the 
FORMAT statements. If any symbol is 
already entered in the dictionary, that 
entry is modified, if necessary, to reflect 
any new information about the symbol under 
consideration. For example, if the symbol 
is in COMMON, an indicator in the diction- 
ary is set on. 



Entries are made to the overflow table 
(refer to Appendix H) for: 

• Statement numbers. 

• Dimension information. 



To see that the associated variable for 
each unit is a nonsubscripted integer 
variable. 



PHASE 10E (IEJFJAAO) 



Phase 10D also accumulates the number of 
direct access data sets in DEFINE FILE 
statements in the DEFILCT field of the 
communication area. This field is examined 
by Phase 25 to determine if a DEFINE FILE 
statement was included in the source 
module. (If a DEFINE FILE statement was 
included in the source module. Phase 25 
generates, as a part of the object module, 
a calling sequence to the file definition 
section of IHCDIOSE — the direct access 
I/O data management interface.) 

For COMMON and EQUIVALENCE statements, a 
special form of intermediate text is creat- 
ed. (Refer to Appendix F for the format.) 
These special forms of text transmit the 
corresponding statements to Phase 12. 

Note: The input to Phase 12 is COMMON and 
EQUIVALENCE text mixed with regular inter- 
mediate text. If all COMMON and EQUIVA- 
LENCE text precedes all other intermediate 
text, Phase 12, at its conclusion, does not 
reposition the SYSUT1 data set to its 
beginning. (That is. Phase 14 can start 
reading SYSUTl from where it is 
positioned.) In either case. Phase 14 
deletes COMMON and EQUIVALENCE text when it 
is encountered. 



Phase 10E is entered after the comple- 
tion of Phase 10D. The functions of the 
phase are: 

• Creation of intermediate text. 

• construction of dictionary and overflow 
table entries. 

• Completion of the preparation of the 
source statement listing if the SOURCE 
and NOADJUST options are in effect. 



If the NOADJUST option is specified, the 
input to Phase 10E resides on the SYSIN 
data set. If the ADJUST option is speci- 
fied, the input to Phase 10E resides on the 
SYSUT2 data set. 



Phase 10E processes SFs (statement 
functions), the executable statements of 
the source module, and any FORMAT state- 
ments interspersed among them. As each SF, 
executable, or FORMAT statement appears in 
the input stream, intermediate text is 
prepared and corresponding entries are made 
to the dictionary and the overflow table. 
The intermediate text prepared by Phase 10E 
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represents the executable source module 
statements. The dictionary and overflow 
table entries complement intermediate text. 
(For the formats of the intermediate text 
and the dictionary and overflow table, 
refer to Appendixes F and H, respectively.) 
If any syntactical errors are encountered 
during the processing of an SF, executable, 
or FORMAT statement, error intermediate 
text entries are made immediately following 
the intermediate text entries for the 
statement in which the error was detected. 



CREATING INTERMEDIATE TEXT FOR STATEMENT 
FUNCTIONS, EXECUTABLE STATEMENTS, AND 
FORMAT STATEMENTS 



Phase 10E produces intermediate text for 
each SF and executable statement, and for 
any FORMAT statements among them. (Refer 
to Appendix E for a description of the 
source statement scan required for inter- 
mediate text preparation. ) 



When the END statement or an end- of- file 
(EOF) is encountered. Phase 10E passes 
control either to Interlude 10E (IEJFJGAO) 
for SPACE compilations, or to Phase 12 for 
PRFRM compilations. 



Note: When the END statement is encoun- 
tered. Phase 10E determines, by reading the 
next record of the input data set, if a new 
compilation, after the current one, is to 
be initiated. If an end-of-file is encoun- 
tered. Phase 10E indicates to Phase 1, by 
setting a bit in the communication area, 
that the current compilation is the last 
compilation. If another record exists. 
Phase 1 initiates a new compilation at the 
end of the current one. 

Figure 8 illustrates the data flow with- 
in the phase. The input data set (SYSIN or 
SYSUT2), and the output data sets (SYSUT1 
and SYSPRINT) are not repositioned after 
Phase 10D. Therefore, Phase 10E can con- 
tinue to read from SYSIN or SYSUT2 and to 
write onto SYSUT1 and SYSPRINT. 

Chart 60 illustrates the overall logic 
and the relationship among the routines of 
Phase 10E. Table 8, the routine directory, 
lists the routines used in the phase and 
their functions. 



For a subscripted expression appearing 
within a statement, a unique intermediate 
text entry of two words is made (refer to 
Appendix F) . The offset of the subscripted 
expression (for which a field in this 
unique text entry is reserved) is computed 
by Phase 10E. For a discussion of this 
aspect of subscripted expressions, refer to 
Appendix G. 



Note: Phase 10E performs a special check 
for the READ, WRITE, and FIND direct access 
I/O statements. (The direct access FIND 
statement is treated, at compile-time, as a 
direct access READ statement without format 
and list.) A check is performed to see if 
the parameter indicating the relative posi- 
tion, within the data set, of the record to 
be read or written involves an arithmetic 
expression other than a constant or single 
nonsubscripted variable. If the parameter 
involves such an expression, Phase 10E 
generates the intermediate text, in the 
form of an arithmetic expression, that is 
required to evaluate the expression. Phase 
10E then sets a switch (FDATEMP) in the 
communication area. This switch indicates 
to Phase 15 that main storage for a special 
work area must be allocated. The special 
work area is used, at object-time, to 
contain the value of the expression. 



SYSIN for 
NOADJUST 
option; 
SYSUT2 for 



j SFs and Exe- j 
| cutable State- j 
| ments of the 
I Source Module 



ADJUST option L- 



Main Storage | Dictionary 

| and Overflow | 
| Table j 
i j 

Figure 8. Phase 10 E Data Flow 




Phase 10E \- 



r 1 

| Intermediate | SYSUT1 or 
| Text | Main Storage 
I I 

I I 

j 

r 1 

| Dictionary | Main Storage 
-+\ and Overflow j 
| Table j 
i j 

1 

| Source j SYSPRINT (if 
I Statement | SOURCE and 
| Listing | NOADJUST 

l j options are 

in effect) 



Section 2: Discussion of ComDiler Phases 35 



CONSTRUCTING DICTIONARY AND OVERFLOW TABLE 
ENTRIES 



Addresses are assigned in the order in 
which they are listed. 



Phase 10E makes entries to the diction- 
ary for: 



• Variables. 

• Constants. 

• Subprograms . 

• Data set reference numbers. 



(Refer to Appendix H for the format and 
content of these entries.) 



Phase 10E makes entries to the overflow 
table for: 



• Subscripted expressions appearing in 
the executable statements. 

• Statement numbers associated with FOR- 
MAT statements or executable state- 
ments . 



(Refer to Appendix H for the format and 
content of these entries.) 



If the object listing facility of the 
compiler has been enabled and if the object 
listing option is specified, Phase 12 plac- 
es the names of all variables and constants 
used in the source module and their corres- 
ponding relative addresses into the SORSYM 
load module. (SORSYM was previously loaded 
into main storage by Phase 1.) 



When the SORSYM module is full, all 
subsequent variables and constants are 
ignored and do not appear on the object 
module listing. 



Processing of the EQUIVALENCE text 
occurs after the assignment of addresses to 
variables and arrays in COMMON but before 
the assignment of addresses to other dic- 
tionary entries. 



EQUIVALENCE text processing assigns 
relative positions to the variables speci- 
fied in the EQUIVALENCE statements. These 
relative positions are indicated in a 
table, which is created and used to assign 
relative addresses to the variables accord- 
ing to their position in the table. 



PHASE 12 (IEJFLAAO) 



Phase 12 is entered either after the 
completion of Interlude 10E for SPACE com- 
pilations, or after the completion of Phase 
10E for PRFRM compilations. The functions 
of the phase are: 



After the assignment of addresses to 
real and integer constants, Phase 12 pre- 
pares a branch list table, which is used to 
control branching within the object module. 



During the assignment of addresses by 
Phase 12, ESD, TXT, and RLD card images are 
generated for section definitions, liter- 
als, and external references. 



• Address assignment. 

• EQUIVALENCE statement processing. 

• Branch list table preparation. 

• Card image preparation. 

• Preparation of a storage map if the MAP 
option is specified (a minor function). 



Address assignment is the allocation of 
relative storage locations to: 



Variables and arrays in COMMON. 

Variables and arrays not in COMMON. 

Equated variables. 

Variables in subscripted expressions. 

Double-precision constants. 

Real and integer constants. 



In addition to the preceding functions, 
Phase 12 prepares a storage map to indicate 
all address assignments made during the 
phase. 



After the completion of Phase 12 pro- 
cessing, control is passed to Phase 14. 



Figure 9 illustrates the data flow with- 
in the phase. 



Chart 70 illustrates the overall logic 
of Phase 12 and the relationship among its 
routines. Table 9, the routine directory, 
lists the routines used in the phase and 
their functions. 
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ADDRESS ASSIGNMENT 



An effective address in IBM System/ 360 
Operating System (a base-displacement 
address) is the displacement in an instruc- 
tion added to the value in a base register. 
This yields a two-byte address wherein the 
first six bits represent a general register 
used as a base register and the last ten 
bits represent the displacement. All sym- 
bols in the object module generated by the 
compiler are referenced by this two-byte 
address . 

The base-displacement address is 
assigned through the use of a location 
counter, which is initialized and then 
incremented by the number of words needed 
in main storage to contain the variable, 
array, constant, address constant, or 
equated variable assigned an address. If 
more than 4096 bytes are needed, a new base 
register is assigned. 

There are only two instances in which 
the location counter may be incremented 
when no address is assigned: 



The first occurs after the variables in 
COMMON are assigned addresses. A new 
base register is assigned to the loca- 
tion counter so that variables not in 
COMMON have different base registers 
than variables in COMMON. 



• The second may occur before the assign- 
ment of addresses to double-precision 
constants that are not in COMMON. The 
location counter is adjusted to a 
double- word boundary in order to accom- 
modate double-precision constants. 



When a variable is assigned an address, 
that address is placed in the chain field 
of the dictionary or overflow table entry 
for the variable. 



FORMAT statements are assigned addresses 
during the execution of Phase 14. All 
phases after Phase 12 assign addresses 
whenever a constant or work area is 
defined. 
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EQUIVALENCE STATEMENT PROCESSING 



The EQUIVALENCE text is processed by 
Phase 12 so that equated variables are 
assigned to the same address. 



The following terms are used in the 
description of EQUIVALENCE processing: 



• EQUIVALENCE group — the variable 
and/or array names between a left and 
right parenthesis in an EQUIVALENCE 
statement. 

• EQUIVALENCE class — two or more EQUIV- 
ALENCE groups that have the following 
characteristic. If any EQUIVALENCE 
groups contain the same element, these 
groups form an EQUIVALENCE class. 
Further, if any other group contains an 
element in this class, the other group 
is part of this class, etc. 

• Root — the member of an EQUIVALENCE 
group or class from which all other 
variables in that group or class are 
referenced by means of a positive dis- 
placement. 

• Displacement — the distance, in bytes, 
between a variable and its root. 

The root of an EQUIVALENCE group is 
assigned an address, and all other varia- 
bles in the group are assigned addresses 
relative to that root. 

To determine the root and the displace- 
ment of the other elements in the group 
from the root, the first element in the 
EQUIVALENCE group is established initially 
as the root. The displacement for the 
other elements (in relation to the root) is 
calculated by subtracting the offset of the 
root from the offset of the variable whose 
displacement is being calculated. (The 
offset for subscripted variables is con- 
tained in the EQUIVALENCE text created by 
Phase 10D. The offset for nonsubscripted 
variables is zero. ) 

If the resulting displacement is nega- 
tive, the root is changed. The new root is 
the variable whose displacement was being 
calculated. Whenever a new root is 
assigned to an EQUIVALENCE group, the pre- 
viously calculated displacements must be 
recalculated. 

The root and the displacements in each 
group are entered in an EQUIVALENCE table, 
which is used by the storage assignment 
routines of Phase 12 to assign addresses to 
equated variables. (Refer to Appendix I 
for the table format.) 



Note: Phase 12 generates intermediate text 
for non syntactical errors encountered in 
COMMON and EQUIVALENCE statements during 
relative address assignment. (The internal 
statement number for the error messages 
that are generated from this intermediate 
text by Phase 30 is 0000.) The amount of 
intermediate text for such errors depends 
on whether the SPACE or the PRFRM option is 
in effect. 

If the SPACE option is in effect, the 
amount of error text is limited by the size 
of the first internal text buffer for the 
SYSUT2 data set. Phase 12 does not write 
any of the error text onto the SYSUT2 data 
set; it places the text into the above 
buffer. (The contents of the buffer are 
written onto SYSUT2 by Phase 14.) If the 
buffer is filled before COMMON and EQUIVA- 
LENCE processing is completed, Phase 12 
continues such processing, but does not 
generate additional error text. If the 
buffer is not filled before COMMON and 
EQUIVALENCE processing is completed. Phase 
12 places the displacement of the next 
available location within the buffer into 
the FTXTPTRB field in the communication 
area. Phase 14 starts placing its inter- 
mediate text output at the location indi- 
cated by this field. 

If the PRFRM option is in effect, there 
is no limitation on the amount of inter- 
mediate text generated by Phase 12 for 
COMMON and EQUIVALENCE statement errors. 
Phase 12 starts placing the error text into 
the first text buffer in the first text 
buffer chain for the SYSUT2 data set. When 
that buffer is full, the next buffer in the 
chain is used, etc. When all of the COMMON 
and EQUIVALENCE text is processed, the 
displacement of the next available location 
within the current buffer is placed into 
the FTXTPTRB field in the communication 
area. Phase 14 starts placing its inter- 
mediate text output at the location indi- 
cated by this field. 



BRANCH LIST TABLE PREPARATION 



The branch list table is initialized by 
Phase 12 (and is completed by Phase 25) . 
This table is used by the object module to 
control the branching process. (Refer to 
Appendix J for the table format.) Each 
statement number referenced in a control 
statement is assigned a position relative 
to the start of the branch table. This 
position is indicated to Phase 25 by a 
relative number, which replaces the chain 
field of the corresponding statement number 
entry in the overflow table. 
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In the assignment process, the statement 
number chains in the overflow table are 
scanned sequentially. Each time an entry 
for a statement number indicates a ref- 
erenced statement other than the statement 
number of a FORMAT or specification state- 
ment, a counter associated with the branch 
list table is incremented by 4. (Four 
bytes are required for the referenced 
statement number and the address that will 
be assigned to the number by Phase 25.) 
The current contents of that counter are 
then placed in the chain field of the 
corresponding overflow table entry. 



This counter is initialized to 0. 
Therefore, the first statement number in 
the first chain is assigned the number 0, 
the second statement number is assigned the 
relative number 4, the third statement 
number is assigned the relative number 8, 
and so on. After all statement numbers are 
assigned, the location counter is incre- 
mented by an amount equal to the size of 
the branch list table (in bytes). 



CARD IMAGE PREPARATION 



Several card images are prepared during 
the execution of Phase 12. This involves 
setting up the proper formats for the card 
images and inserting the pertinent informa- 
tion into those formats. The card images 
prepared are indicated below, along with 
their functions. For a more complete dis- 
cussion of the use and format of these 
cards, refer to the publication IBM 
System/ 360 Operating System: Linkage Edi- 
tor, Program Logic Manual . 



The cards generated by Phase 12 are: 



• ESD-0 This is the section definition 
card for the source module being 
compiled. 



RLD This card contains the address 
of the location at which the 
address of each external subpro- 
gram will be loaded at object 
time. There may be several such 
cards . 



PHASE 14 (IEJFNAAO) 

Phase 14 is entered after the completion 
of Phase 12. The functions of the phase 
are: 

• FORMAT statement processing. 

• READ/WRITE/FIND statement processing. 

• Replacing dictionary pointers. 

• Miscellaneous statement processing. 



The FORMAT statement processing converts 
the intermediate text for FORMAT statements 
into a form acceptable to IHCFCOME and 
creates TXT card images. These card images 
are used by IHCFCOME to set up the format 
of the list items for the I/O operations of 
the compiled source module. For a discus- 
sion of IHCFCOME, refer to Appendix L. 



The processing for READ /WRITE/FIND 
statements consists of checking the compo- 
nents of the statements for validity, pro- 
cessing implied DOs within the statements, 
and rearranging the intermediate text for 
the statements. 



Phase 14 replaces dictionary pointers in 
the intermediate text with the appropriate 
address assigned by Phase 12, a data set 
reference number, or a statement function 
number. (For SPACE compilations, the main 
storage occupied by the dictionary is freed 
by Phase 14.) 



• ESD-2 This card is produced for exter- 
nal subprogram names. There may 
be several such cards. 



• ESD-5 This is the section definition 
card for COMMON (if a COMMON 
statement exists in the source 
module being compiled) . 



• TXT This card is produced for con- 
stants that have been entered in 
the dictionary. There may be 
several such cards. 



Upon completion of the Phase 14 process- 
ing, control is passed either to Interlude 
14 (IEJFNGAO) for SPACE compilations, or to 
Phase 15 for PRFRM compilations. 



Figure 10 illustrates the data flow 
within the phase. 



Chart 80 illustrates the overall logic 
of Phase 14 and the relationship among its 
routines. Table 12, the routine directory, 
lists the routines used in the phase and 
their functions. 



Section 2: Discussion of Compiler Phases 
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FORMAT STATEMENT PROCESSING 



A FORMAT statement is composed of one or 
more format specifications that define an 
I/O format. For a discussion of the physi- 
cal structure of a FORMAT statement refer 
to the publication IBM System/ 360 Operating 
System; FORTRAN IV (E) Language . 



Each FORMAT statement is examined begin- 
ning with the first FORMAT code. For each 
FORMAT code obtained, a specific processing 
routine is called (refer to Table 11). The 
processing of each routine consists of 
entering the required information for the 
FORMAT code into TXT card images. These 
images are composed of 1-byte units con- 
taining 2 hexadecimal digits. Each byte 
contains one of the following: 

• An adjective code, which indicates to 
IHCFCOME the format conversion 
(H,I,F,P,X, etc.), a group or field 
count, or the end of a FORMAT state- 
ment. 

• A number that represents the actual 
field count, field length, group count, 
or decimal length. 



group, or the right parenthesis that 
ends a FORMAT statement.) 

Adjective Code, Field Length, and Deci- 
mal Length. (Entered for FORMAT speci- 
fications D, E, and F. ) 

Adjective Code, Field Length, and 
Literal. (Entered for FORMAT specifi- 
cations H and apostrophe.) 



As the specific information is entered 
into TXT card images, addresses are 
assigned by incrementing the location 
counter (according to the amount of storage 
required to contain the contents of a TXT 
card image) . 



During the processing of a FORMAT state- 
ment, various accumulators are used to 
determine the record length. That length 
is compared to the user-specified length 
(indicated by the LINELNG option). If the 
record length is greater than the specified 
length, a warning indicator is placed in 
intermediate text. If the user has not 
specified a record length, the standard 
length is used. 



One of the following is entered 
TXT card image: 



into 



• Adjective Code and Number. (Entered 
for FORMAT specifications P,I,T,A, and 
X, and for entries made to indicate a 
field or group count. ) 

• Adjective Code. (Entered for a slash, 
the right parenthesis that ends a 



READ/WRITE/FIND STATEMENT PROCESSING 



READ/WRITE/FIND statement processing 
involves four operations. The first is a 
check for the validity of the symbol used 
as the data set reference number. An 
indicator for the end of the 
READ/WRITE/FIND statement is made by enter- 
ing an end- of -statement indicator in the 
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intermediate text before any entries for 
the I/O list. This allows Phase 20 to 
handle the I/O list as a separate statement 
in intermediate text. 



The second operation is the replacement 
of dictionary pointers in intermediate text 
(for the symbols in the I/O list) with 
addresses assigned by Phase 12. This 
includes a check for the validity of the 
symbols in the I/O list. When an invalid 
symbol (a symbol other than a variable or 
array name) is encountered, an error condi- 
tion is noted in the intermediate text and 
the remainder of the I/O list is deleted. 



MISCELLANEOUS STATEMENT PROCESSING 



Statement function (SF) definition 
statements are assigned a unique SF number 
by Phase 14. This number is used to 
reference the SF within an associated 
branch list table in the compiled source 
module (refer to Phase 25) . This unique 
number is assigned, in sequence beginning 
with 01 , to each SF in the program and is 
moved to the dictionary entry for the name 
of that SF. This number also replaces the 
pointer field of the intermediate text 
entry for the SF. 



The third operation is to check for and 
process implied DOs, which are recognized 
by a left parenthesis within a READ/WRITE 
statement. For each encounter, an implied 
DO adjective code is inserted in the inter- 
mediate text for the READ/WRITE statement. 
When the end of an implied DO is recognized 
(right parenthesis), an end DO adjective 
code is inserted in the intermediate text. 



The text for RETURN, DO, GO TO, IF, 
PAUSE, and STOP statements is examined to 
determine if the statement in question ends 
a DO loop. If it does, an error condition 
is noted in the intermediate text. In 
addition to this error check, if the adjec- 
tive code for a RETURN statement appears 
within a main program, that adjective code 
is changed to the adjective code that 
represents a STOP statement. 



The fourth operation is to rearrange the 
READ/WRITE statement entries so that later 
phases can process the statement correctly. 
The implied DO variable and parameters are 
placed ahead of any subscripted variables 
(whose intermediate text is also 
rearranged) . 



A statement number entry in the inter- 
mediate text, other than a FORMAT statement 
number, is moved unchanged from the input 
buffer to the output buffer. A FORMAT 
statement number is treated as follows: 



• If the number is not referenced, a 
warning condition is noted in the 
intermediate text. 



REPLACING DICTIONARY POINTERS 



In the intermediate text entries, except 
for the END and FORMAT statements, diction- 
ary pointers are replaced by: 



• The address assigned and placed in the 
dictionary chain field by Phase 12 if 
the pointer refers to an entry for a 
variable, constant, array, or external 
function. (The assigned addresses are 
obtained from the chain address fields 
of the affected entries in the diction- 
ary.) 



A data set reference number if the 
pointer refers to a data set reference 
number . 



• A statement function number if the 
pointer refers to a statement function. 



• If the number is associated with a 

FORMAT statement that ends a DO loop, 

an error condition is noted in the 
intermediate text. 



• The contents of the location counter 
are entered in the chain address field 
of the associated overflow table entry. 



BACKSPACE, REWIND, and END FILE state- 
ments are examined to verify that the data 
set reference number is a valid symbol. 



Intermediate text for computed GO TO 
statements is rearranged, putting the vari- 
able and the number of statement numbers 
before the statement numbers themselves. 



Any intermediate text for COMMON and 
EQUIVALENCE statements is deleted by Phase 
14 since that text is no longer used. 
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PHASE 15 (IEJFPAAO) 



Phase 15 is entered either after the 
completion of Interlude 14 for SPACE compi- 
lations, or after the completion of Phase 
14 for PRFRM compilations. The functions 
of the phase are: 

• Reordering intermediate text. 

• Modifying intermediate text. 

• Assigning registers. 

• Creating argument lists. 

• Checking for statement errors. 

All of the above functions are performed 
for the processing of statements that can 
contain arithmetic expressions; only the 
error checking function is performed for 
the remaining statements- 
Phase 15 reorders the sequence of inter- 
mediate text words within: (1) statements 
that can contain arithmetic expressions 
(arithmetic, arithmetic IF, CALL, and 
statement functions), and (2) DEFINE FILE 
statements. As intermediate text words are 
being reordered, they are modified, depend- 
ing on the operators and operands, to a 
form closely resembling an instruction for- 
mat. When the intermediate text words are 
modified, registers are assigned, when nec- 
essary, to the operands of all arithmetic 
operators. Argument lists for subprogram 
and statement function references are 
created, and in-line function references 
are processed by generating the appropriate 
instruction format intermediate text or 
intermediate text word for an in-line func- 
tion call. During the input text process- 
ing, errors pertaining to DO loops, arith- 
metic IF statements, statement numbers, 
function arguments, and operand usage and 
form are recognized, and the appropriate 
error messages are given. 

Upon completion of Phase 15 processing, 
control is passed either to Interlude 15 
(IEJFPGAO) for SPACE compilations, or to 
Phase 20 for PRFRM compilations. 

Figure 11 illustrates the data flow 
within Phase 15. 



Chart 90 illustrates the overall logic 
of Phase 15 and the relationship among its 
routines. Table 15, the routine directory, 
lists the routines of the phase and their 
functions. 



REORDERING INTERMEDIATE TEXT 



For Arithmetic Expressions 



Phase 15 reorders the sequence of inter- 
mediate text words within arithmetic 
expressions so that the resulting code 
generated by Phase 25 will cause evaluation 
of arithmetic expressions according to a 
hierarchy of operators. The desired order 
is defined by a hierarchy of the specific 
operations as represented by adjective 
codes and is determined by a comparison of 
forcing values (a forcing value indicates 
an operator's priority in the hierarchy of 
operators). (Refer to Appendix I, Figure 
77, for a list of the various operators and 
their corresponding forcing values.) 
Depending on the operator in an intermedi- 
ate text word and its relative position in 
the hierarchy of operators, that intermedi- 
ate text word is either: 

• Processed (this consists of modifying 
the intermediate text word by replacing 
the adjective code field and the 
mode/type field, when necessary, with a 
machine operation code and a register 
number, respectively) , or 

• Stored in an operations table or sub- 
script table (refer to Appendix I, 
Figures 78 and 79) . 

The operations and subscript tables 
function as pushdown tables in which the 
top entry in the table is the most recently 
entered item. (This process is known as 
LIFO: last in, first out.) 

The actual reordering of intermediate 
text words is controlled by a routine 
(FOSCAN) that scans the input intermediate 
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text words. This routine compares the 
forcing values of the various adjective 
codes under consideration to determine 
their disposition. Each adjective code has 
a left and a right forcing value. The 
right forcing value applies to the adjec- 
tive code within the current input inter- 
mediate text word. The left forcing value 
applies to the adjective code within the 
top entry in the operations table. The 
adjective code of the first intermediate 
text word of an arithmetic statement has 
the highest left forcing value of any 
adjective code except for the end- of - 
statement indicator. 



The first intermediate text word of any 
arithmetic statement is first written on 
the output data set and then entered in the 
operations table. The next word of the 
input intermediate text for this statement 
is then obtained and examined. If it is 
subscript intermediate text, it is entered 
in the subscript table. The following word 
is then obtained and examined. When the 
word (in the operations table) containing 
the subscripted variable is processed, the 
related subscript intermediate text is 
obtained from the subscript table. The 
related subscript intermediate text is 
always the top entry in the subscript 
table. 



For DEFINE FILE Statements 



Phase 15 reorders the intermediate text, 
created by Phase 10D, for DEFINE FILE 
statements to facilitate the generation of 
TXT card images for the parameter lists 
included in those statements (refer to 
Appendix F) . (The parameter lists are 
required at object- time by IHCDIOSE, the 
direct access I/O data management inter- 
face. ) 

Each parameter list is reordered into a 
three -argument format that contains the 
parameters which define the corresponding 
direct access data set. Phase 15 generates 
an intermediate text word containing a 
constant of three, and places this text 
word prior to each of the parameter lists. 
The constant three indicates that a param- 
eter list occupies the next three inter- 
mediate text words. 

In addition, Phase 15 generates an 
intermediate text word containing an end 
mark, and places this text word after each 
parameter list. The end mark indicates the 
end of a parameter list. The text word 
containing the end mark that is generated 
for the last parameter list also contains 
the internal statement number (ISN) that 
Phase 10D assigned to the DEFINE FILE 
statement. 



If the word obtained from the input 
intermediate text is not a subscript inter- 
mediate text word, the right forcing value 
of that word is compared to the left 
forcing value of the top entry in the 
operations table. If the right forcing 
value is greater than or equal to the left 
forcing value, the top entry of the opera- 
tions table is forced out, processed, and 
written on the output data set. If the 
right forcing value is less than the left 
forcing value, the current word of the 
input intermediate text is entered into the 
operations table. The next input inter- 
mediate text word is then obtained. This 
comparison process continues until the 
first entry (for the statement under 
consideration) made in the operations table 
is forced out (by the end mark) and proc- 
essed. In this way, the input data set is 
reordered when it leaves Phase 15 as the 
output data set. 



If an attempt is made to enter informa- 
tion in the operations or subscript table 
when they are full, an error condition is 
recognized. An error intermediate text 
word, which indicates that the statement is 
too long and should be subdivided, is 
generated and placed at the end of the 
intermediate text words for the statement 
containing the error. 



MODIFYING INTERMEDIATE TEXT 



As intermediate text words for an arith- 
metic expression are being reordered, they 
are modified, depending on the operators 
and operands, to a form closely resembling 
an instruction format. The contents of the 
adjective code field for arithmetic opera- 
tors (unary minus (u) , ♦, -, *, and /) are 
replaced by the appropriate machine opera- 
tion code. The contents of the mode field 
are replaced by a register number when the 
operator and operands require a register 
assignment. 



Note: Phase 15 allocates main storage for 
a special work area if the FDATEMP field in 
the communication area is nonzero. Phase 
10E makes the FDATEMP field nonzero if it 
encounters a direct access I/O statement in 
which the parameter that indicates the 
relative position within the data set of 
the record to be read or written involves a 
subscripted expression. Phase 10E also 
generates the intermediate text, in the 
form of an arithmetic expression, that is 
required to evaluate the subscript expres- 
sion. 
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Phase 15 inserts the address of the work 
area back into the FDATEMP field. Phase 25 
obtains the address and inserts it into the 
store instruction that places the value of 
the expression into the work area. In 
addition. Phase 25 includes the address of 
the work area as a part of the calling 
sequence to IHCFCOME that is generated for 
the I/O statement. At object-time, 
IHCFCOME passes the address to IHCDIOSE 
(the direct access data management I/O 
interface) . IHCDIOSE needs the contents of 
that address in order to determine which 
record is to be read or written. 



ASSIGNING REGISTERS 



There are eight single-argument, in- 
line functions: IFIX, FLOAT, DFLOAT, 
SNGL, DBLE, ABS, IABS, and DABS. 
Instructions are generated to perform 
the functions of the SNGL and DBLE 
in-line functions. For the remaining 
single-argument, in-line functions, a 
word in the following format is gener- 
ated: 



j in-line 
| function 
j adjective 
| code 
I'- 



ll byte 
l 



r t t 1 

| | | code number | 

R2 jRl j for the | 

j | in-line function| 

I I I 
-I 



|1 byte 
-X 



| 2 bytes 
.j. 



Registers are assigned by Phase 15 
according to the adjective code encountered 
and the mode of the operands. There are 
eight registers (general registers 0, 1, 2, 
and 3; floating-point registers 0, 2, 4, 
and 6) that may be assigned by Phase 15. 
When a register is required for a particu- 
lar operation and one is not available, the 
contents of the required register are 
transferred to a work area. That register 
acquires "available" status and is then 
used for the operation. 

Register assignments are made by Phase 
15 according to the following rules: 

• The instruction generated for the add 
operator and the floating-point multi- 
ply operator requires that one of its 
operands be in a register. The 
instruction generated for the multiply 
operator for integer quantities 
requires that the multiplicand (left 
operand) be in an odd register. The 
even register that precedes the multi- 
plicand must be made available, unless 
it already contains the multiplier. 

• The instruction generated for the sub- 
tract operator and the divide operator 
for real quantities requires that its 
left operand be in a register. 

• For integer division, the dividend must 
be in an even- odd register pair. 

• A work register is assigned to each 
subscript expression to aid in the 
computation of subscript expressions by 
Phase 20. 

• Exponentiation requires library subpro- 
grams; therefore, a specific register 
is required to contain the result of 
the subprogram execution. 

• Registers are assigned to single and 
double in-line functions, as follows: 



Depending upon the specific in-line 
function, up to three registers are 
assigned by Phase 15. For ABS, IABS, 
and DABS, only an argument register is 
required. This register is indicated 
in the Rl field; the R2 field is made 
zero. For IFIX, FLOAT, and DFLOAT, 
three registers are required: an argu- 
ment register, a result register, and a 
work register. The argument register 
is indicated in the Rl field, the 
result register in R2. The work reg- 
ister is the register preceding Rl. 

For in-line functions with two argu- 
ments, an in-line call word is generat- 
ed with the same format as for single- 
argument, in-line functions. Phase 15 
assigns a register to each argument in 
a double- argument, in-line function. 
The first argument register is 
indicated in the Rl field; the second 
argument register is indicated in the 
R2 field. Rl is used as the result 
register. 



CREATING ARGUMENT LISTS 



To assist Phase 25 in the generation of 
the object module instructions , a list of 
arguments is created when an adjective code 
is encountered that represents a call to a 
subprogram or to a statement function. The 
argument list is preceded by an intermedi- 
ate text word that defines the specific 
function call. The first word of the 
argument list contains the number of argu- 
ments in the list, and is followed by an 
intermediate text word for each argument. 
The total number of arguments in all lists 
created by Phase 15 is kept in the communi- 
cation area to be used by Phase 20 process- 
ing. 
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CHECKING FOR STATEMENT ERRORS 



As each statement is processed, Phase 15 
checks for specific error conditions. Gen- 
eral format errors as well as specific 
errors connected with DO statements, arith- 
metic IF statements, statement numbers, and 
argument lists are noted. Following are 
the error checks performed by Phase 15: 

• DO loops are examined to determine if 
the DO variable is redefined, or if a 
DO loop is nested to a depth greater 
than 25. 

• Arithmetic IF statements are examined 
to determine if the arithmetic expres- 
sions contain valid symbols. They are 
also examined to determine if more or 
fewer than three statement numbers have 
been specified- 

• Statement numbers are examined to 
ensure that they are uniquely defined 
and do not indicate transfers to nonex- 
ecutable statements. 

• If a FUNCTION subprogram is being com- 
piled, a check is made to determine 
whether the subprogram name is defined. 

• The members of an argument list are 
examined to determine whether they are 
valid. If a particular list has a 
required length, that list is examined 
to determine if it is of the required 
length. 

If any of the designated error condi- 
tions are encountered, an intermediate text 
word, which contains an adjective code 
indicating an error and a number represent- 
ing the specific error, is generated and 
placed at the end of the intermediate text 
words for the statement in which the error 
was detected. 



PHASE 20 (IEJFRAAO) 



Phase 20 increases the efficiency of the 
object module by decreasing the amount of 
computation associated with subscript 
expressions. A subscript expression can 
recur frequently in a FORTRAN program. 
Recomputation at each occurrence is time- 
consuming and results in an inefficient 
object module. Therefore, Phase 20 
performs the initial computation of any 
given subscript expression and assigns a 
register which, at object time, contains 
the result of this computation. Phase 20 
then modifies (that is, optimizes) the 
intermediate text for subsequent occurren- 
ces of this subscript expression. This 
intermediate text optimization consists 
essentially of replacing the computation of 
the subscript expression, at each recur- 
rence, with a reference to its initial 
value (that is, to the register that con- 
tains the result of the initial 
computation) . The subscript intermediate 
text for each subsequent occurrence of the 
subscript expression can be optimized in 
this manner as long as the values of the 
integer variables in the expression remain 
unchanged. 



In addition, the following functions are 
performed by Phase 20: 

1. Generation of ESD card images for: 

a. Implied external references to any 
required library exponentiation 
subprograms. For example, 
IHCFRXPI (i.e., FRXPI#) , IHCFRXPR 
(i.e., FRXPR#), IHCFIXPI (i.e., 
FIXPI#), IHCFDXPI (i.e., FDXPI#) , 
and IHCFDXPD (i.e., FDXPD#). 

b. Implied external references to 
IHCFCOME (i.e., IBCOM#) , IHCFIOSH 
(i.e., FIOCS#) , and IHCDIOSE 
(i.e., DIOCS#). 

c. Implied external references to 
IHCCGOTO (i.e., CGOTO#) . IHCCGOTO 
is an implicitly called library 
subprogram that aids in the execu- 
tion of computed GO TO statements 
by supplying the object- time 
branch addresses. 



Phase 20 is entered either after the 
completion of Interlude 15 for SPACE compi- 
lations, or after the completion of Phase 
15 for PRFRM compilations. The major func- 
tions of the phase are: 

• Processing of statements that require 
subscript optimization. 

• Processing of statements that affect, 
but do not require, subscript optimiza- 
tion. 

• Creating the argument list table. 



2. Generation of TXT and RLD card images 
for literals generated by Phase 20 and 
argument list table entries . 

3. Generation of TXT card images for each 
three- word parameter list associated 
with the unit numbers that are defined 
in DEFINE FILE statements. (The first 
TXT card image contains the relative 
address at which the first parameter 
list resides at object-time.) 

4. Generation of calling sequences to 
IHCIBERR (that is, IBERR#) when source 
statement errors are encountered. 
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(Refer to Appendix L for a description 
of the IHCIBERR object-time library 
subprogram. ) 



Printing of a storage map for all 
literals generated by Phase 20 , and 
for all implied external references 
made by the source module being com- 
piled, if the MAP option is specified. 

Allocation of storage for the branch 
list table for SF expansions and DO 
statements . 



Upon completion of Phase 20 processing, 
control is passed either to Phase 30 (if 
the NOLOAD option was specified and source 
module errors were detected) , or to 
Phase 25. 



Figure 12 illustrates the data flow 
within Phase 2 . 



Chart A0 illustrates the overall logic 
and the relationship among the routines of 
Phase 20. Table 18, the routine directory, 
lists the routines used in the phase and 
their functions. 



PROCESSING OF STATEMENTS THAT REQUIRE 
SUBSCRIPT OPTIMIZATION 



Phase 20 scans the input text for state- 
ments that may require subscript optimiza- 
tion. Subscript expressions may occur in 
the following statements: 



• Arithmetic. 

• CALL. 

• Arithmetic IF. 

• Input/output lists (input/output lists 
are treated as statements by Phase 20) . 

When Phase 20 encounters one of these 
statements containing a subscripted vari- 
able, the subscript optimization process 
begins. 

An index mapping table (refer to Appen- 
dix I, Figure 80), containing all informa- 
tion pertinent to a subscript expression, 
is used to aid subscript processing. When 
the index mapping table indicates the first 
occurrence of the current subscript expres- 
sion, a register is assigned and a corres- 
ponding entry is made in the index mapping 
table. When a register is not available, 
the register that is currently assigned to 
the subscript expression of least dimension 



Main Storage | Overflow 
I Table 
i 



j Intermediate 
| Text (sub- 
| script text 
| optimized) 



SYSUT2 or 
Main Storage 



Phase 20 



|ESD Card 
| Images for Im- 
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-»JCard Images 
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List Table 
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j Images for 
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j Parameter 
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L 



SYSLIN 
and/or 
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Main Storage j Text j 
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Figure 12. Phase 20 Data Flow 
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is reassigned to the current subscript 
expression. 

If the current subscript expression has 
been encountered previously, the intermedi- 
ate text for its computation can be 
replaced effectively by a reference to the 
register assigned at the first encounter. 
However, redefinition of any integer vari- 
able in the expression invalidates the 
previous computation and prohibits the 
assignment of the same register to the 
current subscript expression. In this 
case, recomputation is necessary and anoth- 
er register must be assigned for the sub- 
script expression. 

During the subscript optimization pro- 
cess. Phase 20 may be required to generate 
literals connected with the array displace- 
ment associated with any given subscript 
expression. (Refer to Appendix G for a 
discussion of the calculation of an array 
displacement. This explanation includes a 
description of the offset and CDL 
(constant, dimension, and length) portions 
of an array displacement.) Literals are 
generated by Phase 20 under the following 
conditions : 

• When the optimization routine encoun- 
ters a value outside the addressable 
range of through 4095 bytes as a 
result of adding the offset (calculated 
in Phase 10E) to the displacement of 
the array variable (calculated in Phase 
15), an offset literal is generated. 
The generation of an offset literal 
allows Phase 25 to produce instructions 
involving these subscripted variables 
without having to assign a new base 
register. 

• Phase 20 generates a literal for each 
component of the CDL portion of the 
array displacement associated with a 
subscript expression except for the 
first component if it is a power of 2. 
In this case, that power, instead of 
the address for the literal C1*L, is 
placed in the subscript text. 

The preceding discussion of subscript 
optimization applies to subscript expres- 
sions that are neither constant nor asso- 
ciated with a dummy subscripted variable. 
These two conditions are discussed in the 
following paragraphs. 

Phase 20 does not assign a register to a 
constant subscript expression which, when 
added to the offset portion of the array 
displacement, lies within the addressable 
range of through 4095 bytes. However, if 
this computation lies outside the above 
range, a register is assigned for this 
constant and an entry is made in the index 
mapping table. 



In addition to normal optimization, a 
base register is assigned to any dummy 
variable so that the variable may be 
addressed during execution of the object 
module. This assignment is entered in the 
index mapping table. 



PROCESSING OF STATEMENTS THAT AFFECT, BUT 
DO NOT REQUIRE, SUBSCRIPT OPTIMIZATION 



In addition to previously mentioned 
statements that require subscript optimiza- 
tion, various other statements that can 
affect the subscript optimization process 
are processed by Phase 20. 



DO and READ Statements 



The DO and READ statements sometimes 
cause the redefinition of the integer 
variable (s) in a subscript expression. Any 
integer variable that is redefined becomes 
a bound variable. Any encounter of a bound 
variable causes Phase 20 to examine the 
subscript expressions that are assigned 
registers in the index mapping table. A 
bound variable in a subscript expression 
invalidates any previous computation for 
that expression and causes a new register 
to be assigned for that expression. 



Referenced Statement Numbers 



When a statement number is referred to 
in other statements (for example, a GO TO 
statement) , Phase 20 does not know if the 
values of previously encountered integer 
variables can still be used by subscript 
expressions containing these variables. 
Because any given variable may now be a 
bound variable. Phase 20 deletes all reg- 
ister assignments (in the index mapping 
table) for subscript expressions involving 
that variable. 



Subprogram Argument 



Any subprogram argument that is an inte- 
ger variable causes redefinition of that 
variable and, therefore, invalidates any 
previous computations of subscript expres- 
sions containing that variable. All reg- 
ister assignments (in the index mapping 
table) for subscript expressions involving 
that variable are deleted. 



Section 2: Discussion of Compiler Phases 47 



CREATING THE ARGUMENT LIST TABLE 



A count of the number of arguments 
contained in the source module for subpro- 
gram and SF (statement function) calls is 
passed to Phase 20 via the communication 
area. This number is used by Phase 20 to 
allocate storage for the argument list 
table. Phase 20 allocates a word (*t bytes) 
for each argument, and inserts the relative 
address of each argument in the argument 
list table. 

If an argument is a subscripted vari- 
able, its address is not known at this 
time. Instructions are generated to load 
the address of this argument into the 
argument list table at object-time. 

The table is used at object-time to 
provide the addresses of argument lists to 
the subprograms arid SFs being called. 
Refer to Appendix J, Figure 87, for the 
format of the argument list table. 

For each subprogram name or SF name 
encountered. Phase 20 generates the 
appropriate calling sequence. A register 
is used to supply the referenced subprogram 
or SF with the address of its argument 
list. Phase 20 also generates RLD and TXT 
card images for each entry in the argument 
list table. 



Several tables (branch list table for 
statement numbers, branch list table for SF 
expansions and DO statements, and base 
value table) are used by the object module 
during execution of the instructions gener- 
ated by Phase 25. These tables are assem- 
bled in their final form by Phase 25. 



In addition to the above functions, 
Phase 25 generates: (1) a listing of ref- 
erenced statement numbers if the MAP option 
is specified, and (2) an object module 
listing if the object listing option is 
specified and if the object listing facili- 
ty of the compiler has been enabled. The 
object module listing contains the machine 
language instructions generated by Phase 25 
and their equivalent assembly language 
instructions. The equivalent assembly lan- 
guage instructions are generated by an 
object listing module (IEJFVCA0) that Phase 
25 loads (via the LOAD macro- instruction) 
into main storage. The object listing 
module is deleted (via the DELETE 
macro-instruction) before control is passed 
to the next phase. 



Upon completion of Phase 25 processing, 
control is passed to Phase 30 (to generate 
error/warning messages and to process the 
END statement) . 



PHASE 25 (IEJFVAA0) 



Figure 13 illustrates 
within Phase 25. 



the data flow 



Phase 25 is entered after the completion 
of Phase 20. The main functions of the 
phase are: 



• Generation 
tions . 



of object module ins true- 



Chart B0 illustrates the overall logic 
and the relationship among the routines of 
Phase 25. Table 20, the routine directory, 
lists the routines used in the phase and 
their functions. 



• Completion of object module tables. 

Phase 25 creates the object coding for 
the FORTRAN source module from the inter- 
mediate text entries and the overflow table 
(refer to Appendix H). TXT card images for 
instructions are generated and then written 
on the SYSLIN data set (if the LOAD option 
is specified) and/or the SYSPUNCH data set 
(if the DECK option is specified) . 



GENERATION OF OBJECT MODULE INSTRUCTIONS 



Phase 25 creates the object module 
instructions from the intermediate text 
entries and the overflow table. These 
instructions are in the RR, RX, and RS 
formats of the System/360 instructions. 



Phase 25 also generates, as a part of 
the object module, a calling sequence to 
the file definition section of IHCDIOSE 
(the direct access data management I/O 
interface) if the FDEFILCT field in the 
communication area is nonzero. That is, if 
a DEFINE FILE statement is included in the 
source module being compiled. 



The control routine (PRESCN) for Phase 
25 obtains each intermediate text entry and 
examines its adjective code. The adjective 
code determines which Phase 25 subroutine 
is to process the current entry or the next 
series of entries. The processing subrou- 
tine generates the required object coding. 
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Figure 13. Phase 25 Data Flow 



Intermediate text entries for operations 
within arithmetic expressions are almost in 
a final instruction format as a result of 
Phase 15 processing. The intermediate text 
words generated by Phase 15, for arithmetic 
expressions, contain all the elements 
required for the RX format instruction: 
operation code, result register, base reg- 
ister, and displacement. When Phase 25 
encounters an adjective code indicating an 
arithmetic expression, control is passed to 
the routine (RXGEN) that generates RX for- 
mat instructions. 



return the new values of variables, used as 
parameters, to the calling program. This 
information consists of the following: 

• Length and address of the variable in 
the subprogram. 

• The relative position of the variable 
in the parameter list of the calling 
program. 

Refer to Appendix I, Figure 81, for the 
format of the epilog table. 



Other intermediate text entries still 
resemble the output generated by Phase 14. 
An adjective code identifies the type of 
entry and possibly several entries that 
follow it. Various Phase 25 subroutines 
analyze these entries and generate the 
appropriate instructions. 



COMPLETION OF OBJECT MODULE TABLES 



Several tables are used by the object 
module during the execution of the instruc- 
tions generated by Phase 25. These tables, 
assembled in their final form by Phase 25, 
are: 



If a subprogram is being compiled, Phase 
25 generates an epilog table when the 
FUNCTION or SUBROUTINE adjective code is 
encountered. The epilog table provides 
Phase 25 (when it encounters the RETURN 
statement) with the information necessary 
for the generation of instructions that 



• The branch list table for referenced 
statement numbers. 

• The branch list table for SF expansions 
and DO statements. 

• The base value table. 
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Branch List Table for Statement Numbers 



Phase 12 allocated storage for a branch 
list table (refer to Appendix J, Figure 85) 
for referenced statement numbers. Each 
statement number referenced by a GO TO, 
computed GO TO, IF, or DO statement was 
assigned a number relative to the start of 
the branch table. This relative number was 
placed in the chain field of the statement 
number entry in the overflow table (refer 
to Appendix H) . 

When an intermediate text entry for a 
statement number definition is recognized 
by Phase 25, the corresponding overflow 
table entry is obtained, and the relative 
number, assigned by Phase 12, is used to 
determine the position of the statement 
number in the branch table. The value of 
the location counter is placed in this 
position and is the actual relative address 
of that statement. 

Two instructions are generated for the 
portion of a FORTRAN statement that ref- 
erences a statement number. The first 
instruction loads the address portion of 
the proper entry in the branch table into a 
general register; the second instruction 
branches to the address placed in that 
general register. 



Branch List Table for SF Expansions and DO 
Statements 



Refer to Appendix J, Figure 86, for the 
format of the branch list table for SF 
expansions and DO statements. 



Base Value Table 



The base value table (refer to Appendix 
J, Figure 88) is continually generated by 
the various phases of the compiler as base 
registers are required for the object cod- 
ing. An object module can only use general 
registers 4, 5, 6, and 7 as base registers. 
(When the object module is entered at 
object- time, these registers are initial- 
ized from entries in the base value table.) 
If the base register requirements for the 
object module extend beyond the four avai- 
lable registers, the base value table is 
used to take special action. 

During compilation (prior to Phase 25) , 
the value for each base register to be used 
by the object module is inserted in the 
base value table, regardless of the general 
register number used as the base register. 
The first entry in the base value table is 
the value placed in register 4; the second 
refers to register 5 ; etc. 

For a source module for which the com- 
piler assigns registers 4 and 5 to ref- 
erence data in COMMON and assigns registers 
6, 7, and 8 to reference data and instruc- 
tions in the object module, the base value 
table contains the values indicated in 
Figure 14. 



A second branch list table is completed 
by Phase 25 for statement function (SF) 
expansions and DO statements. Phase 14 
assigned a unique number to each SF and 
placed this number in the pointer field 
portion of the intermediate text entry for 
each SF. Phase 25 uses this number to 
assign a location in this second branch 
list table when it encounters an SF adjec- 
tive code. The address of the first 
instruction in the SF expansion in question 
is placed in this location. Any statement 
referencing this SF uses the number of the 
SF to obtain this location in the branch 
list table, and branches to the address in 
the location (that is, to the beginning of 
the SF expansion) . 

Phase 25 also assigns each DO statement 
a location in this branch list table. The 
address of the second instruction of the DO 
loop in question is entered in the proper 
location. The object module instruction 
that controls the iteration of the DO loop 
obtains this location in the branch list, 
and branches to the address in the location 
(that is, to the beginning of the DO loop). 



r r t t t t i 

| Register | 4 j 5 j 6 j 7 j 8 j 

| Value | | 4096 | | 4096 | 8192 | 

L L J. J. J. J. J 

Figure 14. Sample Base Value Table Values 



The value 8192 is initially assigned to 
general register 8, and that register num- 
ber is entered in the intermediate text 
entry requiring the base register. Howev- 
er, when Phase 25 encounters this inter- 
mediate text entry with a base register 
number of 8, an instruction is generated to 
load the value 8192 into register 7, and 
general register 7 is used as the base 
register in this instruction. 

In general, when a base register other 
than 4, 5, 6, or 7 is encountered by Phase 
25, the base value table is used to obtain 
the value of that base register, and an 
instruction is generated to load that value 
into register 7. Register 7 is used as the 
base register in the instruction at object- 
time 
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PHASE 30 (IEJFXAAO) 



Phase 30 , the last phase of the 
compiler, may be entered either after the 
completion of Phase 20 processing if the 
NOLOAD option was specified and errors were 
detected in the source module, or after the 
completion of Phase 25 processing. The 
functions of the phase are: 

• Producing error and warning messages . 

• Processing the END statement. 

When Phase 30 is entered from Phase 20, 
only the first function (producing error 
and warning messages) is performed. Howev- 
er, when Phase 30 is entered from Phase 25, 
both functions are performed. 

Upon the completion of Phase 30 process- 
ing, control is passed to Phase 1. 

Figure 15 illustrates the data flow 
within Phase 30. 



the error or warning condition) from the 
mode/type field of that intermediate text 
word. This number is used as an indexing 
value to obtain the length and address of 
the actual message corresponding to the 
specific error or warning detected. 

The length of the message is obtained 
from the message length table. The address 
of the message is obtained from the message 
address table. The actual message is 
obtained from the message text table. 
(Refer to Appendix I for a description of 
the use and format of the message tables.) 

When the message length and the message 
address are obtained. Phase 30 then prints 
the corresponding message on the SYSPRINT 
data set. (For a description of the messa- 
ges capable of being generated by the 
compiler refer to the publication IBM 
System/360 Operating System: FORTRAN IV (E) 
Programmer's Guide . ) 



Chart CO illustrates the overall logic 
and relationship among the routines of 
Phase 30. Table 21, the routine directory, 
lists the routines used in the phase and 
their functions. 



PRODUCING ERROR AND WARNING MESSAGES 



Phase 30 checks the adjective code of 
each intermediate text word for an error or 
warning condition. If one is encountered. 
Phase 30 obtains the error or warning 
number (set up by the phase that detected 



PROCESSING THE END STATEMENT 



When the intermediate text entry for the 
END statement is recognized by Phase 25, 
control is passed to Phase 30. Phase 30 
first produces any error or warning messa- 
ges detected by earlier phases of the 
compiler. Phase 30 then writes both branch 
list tables and the base value table onto 
the output data set(s). Because all three 
of these tables must be relocatable, all 
entries in the tables are entered in RLD 
card images, as well as in TXT card images. 
Phase 30 also creates the END card image 
for the object module. 
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SECTION 3; CHARTS AND ROUTINE DIRECTORIES 

The following charts describe the overall logic of the major components of the FORTRAN 
IV (E) compiler. Routine directories are included for those components that contain 
numerous routines and subroutines. Multiple entries to subroutines are indicated by a 
slash (/). 

Flowchart Conventions 

a********************************************************************************************************************************* 

* FUNCTIONAL SYMBOLS » * 



SAMPLE FLOWCHART 



***C2******* 
USER ENTRY 



THIS CHART AND FROM 



THE TERMINAL BLOCK IS USED TO SHOW USER ENTRY 
AND EXIT POINTS WHEN THE PROGRAM BEING 
FLOWCHARTED IS AVAILABLE TO AN IBM CUSTOMER. 
IT IS ALSO USED AS AN EXIT CONNECTOR WHEN 
THE TO LOCATION IS TO NO SPECIFIC CHART AS IN 
A MULTIPLE USE SUBROUTINE. 



I**D1 ****** 



******£ 1 ****** 



»*F2******* 
USER EXIT 



PREDEFINED 

PROCESS 

BLOCK 



THE INSTRUCTION AT SYMBOLIC LOCATION GOTO 
CALLS A SUBROUTINE NAMED SUBNM. THE LOGIC OF 
SUBNM IS SHOWN ON CHART ZC STARTING AT BLOCK 



> LINE JUNCTION 



****H2*»*****»* 
•VARIABLE RETURN*<- 
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Chart 10. Phase 1 (IEJFAAAO/IEJFAABO) Overall Logic 



IEJFAAAO 
(INITIAL ENTRY) 



IEJFAABO 
(SUCCESSIVE ENTRIES) 



•***A1 ********* 
t « 

» CALLING « 
» PROGRAM « 



SEE TABLE 2 FOR A 
BRIEF DESCRIPTION OF 
THE FUNCTION OF EACH 
PHASE 1 ROUTINE/ 
SUBROUTINE 



»***A3********* 
* « 

» CALLING « 
► PHASE * 

***»***»»»»**** 



*****A4***« ****** 

* * 

* RESET * 
->* COMMUNICATION * 

* AREA * 

* * 
***************** 



♦LOAD INTERFACE * 

* MODULE * 

* (IEJFAGA0) * 

***************** 



FINAL ENTRY 



.* SPACE OR *. PRFRM 

♦PRFRM OPTION IN* 

*. EFFECT •* 



****B5* ******* 
* 

» XCTL TO 
» PHASE 7 

************** 
( IEJFEAAO ) 



* SCAN 

* PARM 

* OPTIONS 

**************** 



REPLACE 
OONAMES 

IN DCBS 
*********** 



* FLUSH OUTPUT * 

* BUFFERS FOR * 

* BLOCKED I/O * 

* • 
***************** 



FREEMAIN 

*****C5********* 

* FREE ALL MAIN 

* STORAGE 
>* ALLOCATED TO 

* COMPILER dY 

* PHASE 3 
**************** 



•«***D2********** 

* * 

* LOAD SORSYM * 
>* MODULE * 

* (IEJFAXAO) * 

* * 
*•**•»•*•*»••**•* 



***»*D3 ********** 

* * 

* CLOSE ALL * 

* DATA CONTROL * 

* BLOCKS * 

* * 
•••••*••••••••••* 



DELETE * 

PERFORMANCE * 

MODULE AND « 

PHASE 5 * 

It************** 



.* SPACE OR *. PRFRM 

*PRFRM OPTION IN* 

*. EFFECT .* 



•••SIZE* 
.* GREATER 
.THAN OR EQUAL 
*.TO 16504 



UAI_.» 1 

*" I 



FREEMAIN V 

•****E3********** 

* FREE ALL MAIN * 
•STORAGE ALLOC. * 

* TO COMPILER * 

* BY PHASE 5 * 



»***E4********* 

CLOSE ALL 

DATA CONTROL 

BLOCKS 



***•*•****•*« 



»*** 



*••* 1 

» » |< 

IFI *-> 
» * I 
• ••* y 
• *• 
Fl *. 
. "ADJUST *. 
•*OR NOADJUST*. 
»• OPTION IN 
*. EFFECT .* 



NOADJUST *-*- 



* OPEN OCBS FOR 

* SPACE AND AD- 
*JUST COMPILAT. 

•*•••••••••••*•« 



OPEN DCBS FOR * 
•SPACE AND NOAD-* 
♦JUST COMPILAT. * 

***************** 



*****G2 *♦♦******* 

• • 

* LOAD * 
>* PHASE 5 ♦< 

♦ (IEJFCAAO) ♦ 

* * 
••••••••••••••*♦♦ 



»»***F3«* ******** 

* DELETE * 

* PERFORMANCE * 
♦MODULE IF PRFRM^ 

* COMPILATION ♦ 

* • 
***•*•»****•**•** 



*»***G3 ****»****♦ 

* • 

* DELETE SORSYM * 

* MODULE IF * *- 

* OPTION IS * 

* IN EFFECT ♦ 
••••*••*♦••••**•• 



•«**»F4********** 

* * 

* DELETE *K 
>* INTERFACE *- 

* MODULE * 

* * 
***•**•**•***••** 

• ••• 



G4 * 1 

* 

»**• j 



»****G4*********« 
•LOAD « 

*—*—*—*_•—«—*—*-« 
-* LOAD PERFORM- « 

* ANCE MODULE « 

* (IEJFAPAO) « 
•••••••••**••••*« 



****G5*******< 



****H2********* 
» « 

» PHASE 5 * 

* (IEJFCAAO) * 



-* OPEN DCBS FOR *<- 

* PRFRM * 

* COMPILATION * 

»**»*»*»*****»»»* 
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Table 2. Phase 1 Main Routine/Subroutine Directory 



j Routine/Subroutine j Function j 

|. + ^ 

IDDNMSCAN | Replaces DDNAMES in the data control blocks (in the interface! 

| module) when requested by the calling program. 

JFREEMAIN j Frees all main storage allocated to compiler by Phase 5. 

LOAD | Loads the performance module into main storage if the PRFRM option j 

is in effect and if the SIZE option is at least 18504. 

IOPNFILES | Opens data control blocks for compiler data sets as indicated byj 

[switches (in the communication area) for options. 

IOPTNSCAN | Scans the compiler options and sets appropriate switches in the] 

communication area. 

| RESTART | Closes all data control blocks for compiler data sets, deletes thej 

(performance module and Phase 5, and initializes compiler for a SPACE | 
compilation. 

IRUNCMPLT | Closes all data control blocks for compiler data sets, frees allj 

| main storage allocated to the compiler, and returns control to thej 
(calling program. 

ISTART1 |Performs housekeeping and loads the interface module, and Phase 5 

into main storage. 

l ± j 
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Chart 11. Interface Module (IEJFAGAO) Routines 



SNEXT (SEE NOTE t ) 



» ANY 

OCBS TO BE 
*. TCLOSED . 



•••••CI ••••*••••• 

• TCLOSE THE • 

• DATA SETS • 

• INDICATED IN *- 
•THE LINKAGE TO • 

• THIS ROUTINE • 
•••••••••••*••••• 



.« IS AN «. 

.» INTERLUDE •. YES 
->». BEING CALLED .« 



••»»C2 •»»•*•♦»» 
•NEXT PHASE/INT • 
->»AS INDICATED IN» 
• CALLING RTN • 

••••••••••••••• 



PRTCTRL (SEE NOTE l) 

••••A3«« •»*»••» 

• * 
» CALLING » 

• ROUTINE • 

••••••••••••••• 



••••*B3********** 

• • 

• MOVE CARRIAGE • 

• CONTROL CHAR. » 

• TO OUTPUT » 

• BUFFER * 
»»•*••••»•»•»»•»» 



»—•—•—•—»—•—»—»—• 



•WRITE CONTENTS •- 

• OF OUTPUT BFR » 

• (SEE NOTE 3) • 

••»•••••••••••••• 



•—•—•-•- 



>• CHECK RESULTS 

• OF WRITE 

* (SEE NOTE 3) 



ERROR 
OR-END-OF 
.DATA SET . 



NOTE 3 

FOR A PRFRM COMPILATION. 
THE PRTCTRL ROJTIimE 
LINKS TO THE PIORTn 
ROUTINE IN THE PER- 
HANCE MODULE. THE PIORTn 
ROUTINE. IN TUKN. _INKS 
TO THE SIORTN ROUTINE 
WHEN I/O IS NECESSARY. 



.* ANY 

.•FURTHER I/O*. NO 
. OPERATIONS 



JNS .* 1 

.*-*H 



•••••£2********** 

• w 
» ISSUE CHECK • 

• MACRO- *- 

• INSTRUCTION » 

• • 
•••*••••••••••••• 



•••••F2********** 

• • 

• ISSUE READ « 
>* MACRO- * 

• INSTRUCTION » 

• • 
••••••••»•••••••• 

•••• 



SIORTN (SEE NOTE 1 ) 

»»»»D3*»»»»»«»* 
•CALLING PROGRAM* 
• ( SEE NOTE 2 ) • 



••••••••••••••• 



••EITHER ». 

ERROR 

OR-END-OF 

.DATA SET . 



L 



NO 

• ••• 
* * 

->• El » 

• • 
»•»• 

**»»#F3»*»#*»»*»* 

• • 

• SET ERROR • 

• OR END-OF- •< 

• DATA SET • 

• INDICATOR • 
••••••••••••••••• 



»»»»»E4»»»* •••»•* 
•SAVE GR14. AND * 
•FOR ERROR. SET ♦ 
->»GR1 TO POINT TO* 
•GR 14. IS. 0. 1* 
* SAVE AREA » 
•••••••••••••••a* 



PATCH (SEE NOTE 1 ) 

»««*E 5* ******** 

* CALLING 

* ROUTINE 

»••••••*••••*** 



* G2 *— > 



•••••G 1 **••****** 

* • 

* ISSUE WRITE » 

* MACRO- *- 

* INSTRUCTION * 

* • 
••••*••••*••••••• 



••••G4**«****«* 
» CALLING * 
* ROUTINE * 

» « 

••*•••••••••••* 



*»#*«C- 5* ********* 

• * 
•PATCH INDICATED* 

-•AREA IN CALLING* 

* ROUTINE * 

••••••••••••••••ft 



NOTE 1 

AN INSTRUCTION TO BRANCH TO THESE ROUTINES IS A 

PART OF THE COMMUNICATION AREA. THESE INSTRUCTIONS 

ARE UABELED FNEXT . FIORTN. FPRTCTRL. AND 

FPATCH FOR SNEXT. SIORTN. PRTCTRL. AND 

PATCH. RESPECTIVELY. WHEN THESE 

ROUTINES ARE NEEDED. A BRANCH TO 

THE PROPER INSTRUCTION IN THE 

COMMUNICATION AREA IS EXECUTED. 

NOTE 2 

THE CALLING ROUTINE MAY BE WITHIN A 
PHASE.- WITHIN ANOTHER INTERFACE 
MODULE ROUTINE. OR WITHIN THE 
PERFORMANCE MODULE. 



COMPILE-TIME I/O RECOVERY PROCEDURE 



*«*«H3********* 

» INTERFACE MOD • 

• AND BSAM RTN • 

* (SEE NOTE 4) * 



NOTE 4 

THE I/O SUPERVISOR IS 
ENTERED FROM THE SIORTN 
OF THE INTERFACE MODULE 
WHEN A READ. WRITE. OR 
CHECK MACRO-INSTRUCTION 
IS ISSUED. 



• ••• 

* * 

» J2 * 

» • 

• ••• 



•***jl ••••••••• 

• • 

• CALLING « 
» PHASE « 

*••••••••••«••• 

CONTINUES 

NORMAL 

PROCESSING 



•••••J2********** 

* RETURN TO » 
♦BSAM, INTERFACE* 

-• MODULE. AND 
•PHASE REQUEST- 

• ING I/O 
•••••••»»•••*•*•• 



1 



NO .* I/O 

». ERROR IN 

». IOS 



•••••J 4 ••••••«••« 

• « 

• RETRY * 
>• APPROPRIATE « 

• NUMBER OF * 

• TIMES * 



.* HAS 
->». ERROR BEEN 
•.CORRECTED. 



••••K 1 ••••••••• 

• • 

•CALLING PROGRAM*<- 



•••••K2********** 

• • 
•PHASE 1 PASSES • 

-•ABORT CODE (l6)»<- 
» TO CALLING • 

• PROGRAM • 
•••••••••••••••*• 



»»*»«K3********** 

• • 

* CALLING * 
-* PHASE XCTL"S »<- 

* TO PHASE 1 * 

• • 
••••••••••••••••• 



•••••K4**** ****** 

• • 

• CALLING PHASE • 
-•SETS ABORT BIT *<- 

• IN COMM AREA • 

• * 
••••••••••••••••• 



•••**KS**« ******* 

* RETURN ABORT * 

* CODE TO BSAM. • 
-* INT MOD. AND * 

•PHASE REQUEST- * 

* ING I/O * 
••••••••••••**••• 
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Chart 12. Performance Module (IEJFAPAO) I/O Routine 



•••»A1 ••••»*•»» 

* SIORTN « 

» ( REFER TO « 
» NOTE 1 ) « 



.* BLOCKING *. 
-••FACT. GREATER. »<- 
• • THAN .* 



r 



.•PHASE 12 OR*. 
LATER IN . 
«. CONTROL .« 



*****34 ********** 

* * 
» UPDATE » 

->*BUFFER SIZE IN * 

* FCOMM * 

* * 
***************** 



PTSTWRl 

*****ci ********** 

• MOVE LOG RCO * 
» INTO OUPT BFR » 
•UPDATE BFR PTR «< 

• AND LOGICAL • 

• RECORD COUNT » 
•••••••••••••a*** 



r 



•****E1 ******** 

• RESET LOGICAL 

• RECORD COUNT. 

• SET "WRITE* 

• BIT. INDICATE 
•POSSIBLE CLOSE 
*•••••*•••••••••• 

•••• 



n 



C2 ». 
.* WAS ». 

.» LAST REQ ». 
.FOR THIS DATA. 
». SET A .» 

•.READ .« 

*• •* 
• YES 



D2 *. 
.» ANY ». 

» RECORDS 

LEFT TO BE 
». DEBLOCKED. 



PGETRCD 

*»**»E2********** 

• MOVE NEXT LOG • 

• RCD INTO RE- • 

• QUESTED AREA. •« 
•UPDATE LOGICAL • 

• RECORD COUNT • 
*«***•*•*•**«•*** 



**** 



-*-•—»—*—* 



INITIATE 

•CHECK-READ* 

OPERATION 



r 



••EITHER 
•READ 
•WRITE" 
. REQUEST 



OR *. YES 



****A5*** ****** 

► CALLING * 

► PHASE * 

*************** 



• ****E}5********* 

• UPDATE 
>*BUFFER POINTERS 

• IN FCOMM 

********** ****** 



.* DOES *. 
.* SPECIFIED * 
.BUFFER POINT 
*.TO ITSELF.* 



L ***** 

l— >* G2 



» ABNORMAL 

RETURN FROM 
►. SIORTN 



HUM • » 1 

.*•* n 



*<- 



• E3 •-> 

* * 

**** 

****»E3»********* 



»•••*•••••*•••••• 



»»•» v 




• ••• 






SIORTN ROUTINE 




FLUSH .». 




PNORMRET V 




IN THE INTERFACE 




Fl *. 




»»»**F2**»******* 




MODULE PERFORMS 




• • *. 




* SAVE * 




THE REQUESTED 




.* WAS A ». NO 


•LOGICAL RECORD • 




OPERATION AND 




». "FLUSH" .» 


>• COUNT AND * 




THEN RETURNS 




•.REQUESTED.* 




* CURRENT I/O * 




CONTROL TO THE 




• • •• 




* PARAMETERS * 




PHASE THAT RE- 




*. .» 




•ft*************** 




QUESTED I/O. 




• YES 




















• ••• 
















* • 
















• G2 «— > 
















* « 
















*»»* 










V 




RETURN V 




PTESTRD .*. 




»****G 1 •••••••• 




•••••G2********** 




G3 ». 




* 


* 


• * 




.* IS *. 




• CALCULATE 


• 


• RESTORE • 




••THIS FIRST *. 


NO 


• RECORD LENGTH 


• 


* REGISTERS » 




r— >*. I/O REQUEST . 




• 


* 


• * 




*.FOR DATA .* 




• 


• 


• • 




*. SET .» 


I 


••••***•»•••••»** 


••••••••••••ft**** 




I *. .* 


V 














»»•» » YES 


***• 












• 


• I 


* 












• 


G3 • 


• Fl 












• 


• 

•••• I 


• 
**** 


V 










V 




.1 


t. 










.»• 





»****D4 ********** 
•SET "CHECK" BIT* 
•(OFF FOR FIRST 

• I/O FOR DATA 

• SET. ON * 

• OTHERWISE) * 
•••••*••••••••••« 



•****E4 ********** 



*••«***** ***•**•* 



****F4*»»*»*»»« 

• SIORTN * 

* (refer to * 

► NOTE 1 ) * 

**•**•****»•**• 



*»***G4*******»»* 
« SET LOGICAL * 

* RECORD COUNT 

* ACCORDING TO 

* LENGTH OF * 

* SHORT BLOCK * 
••••••••••••••••• 



E5 *. 

.* WERE *. 

.•MORE THAN 2* 

.RCDS WRITTEN 

*. ON DATA .* 

*. SET .* 



L 



NO 



n 



*<- 



L •••••• 

I— >* £3 • 



.* IS ». YES 

• .RECORD LENGTH. • 

«. ZERO .• 



SET "WRITE* 

BIT FOR SHORT 

BLOCK 



•—»-»-•- 



»»*»H2»* *****»» 
NORMAL • 
RETURN TO • 
CALLING PHASE « 



PINITWR V 

»»»**J3»**»»*»*»* 

• INITIALIZE • 
•LOGICAL RECORD 
•COUNT TO VALUE 

• OF BLOCKING 

• FACTOR 
••••••••••••••••a 



n 



**** 

»****H4 ********** 

* SET * 

* "READ" BIT. * 
>* INDICATE NO * 

•POSSIBLE CLOSE * 

* * 
•••••••••••••a*** 



*-»-*-*—*—*—*—*—* 

* PERFORM * 

* REQUESTEO * 

* OPERATION * 
••••••••••••••••A 



END-OF-FILE 



•• WAS *. 

» A VALID * 

SHORT BLOCK 
». READ .« 



****J5********* 
» ABNORMAL 
► RETURN TO 
» CALLING PHASE 

*************** 



• PERFORM *- 

• REQUESTEO ♦ 

• OPERATION » 

••••••••»»•»•*»»• 



**»»*K2*»*»****** 

• • 

• SET "CHECK- • 
->• ONLY" BIT FOR » 

• THIS DATA SET » 



*»*»*K3***»****** 

• * 

• INDICATE • 

• NO POSSIBLE •< 

• CLOSE • 

• » 
•••••••••••••••*• 



n 



**** 
• • 

• J4 • 
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Chart 13. Performance Module (IEJFAPAO) End-of -Phase Routine 



••••A3********* 
t « 

* CALLING « 

* PHASE * 
•••••••*••••**• 



#*»«*B3 ********** 

* TURN OFF * 

* 'ALL INT TEXT * 

* IN MAIN * 
•STORAGE* SWITCH* 

* IN FCOMM * 
*•*********•**•«* 



• * *• 


• **• 


.» ANY *. NO 


• 










*. TCLOSED .* 


* 


*. .* 


• ••• 


*. .* 




* YES 





##***D3********** 

* BUILD TCLOSE * 

* LIST AS * 

* INDICATED IN * 

* LINKAGE * 

* PARAMETERS * 
#*•»*»»•»•*»»•♦*• 



»*»*#E2 ********** 
•RESET REQUIRED * 
*FLDS IN FCOMM . * 

* PERFORMANCE *< 

* MODULE • AND • 
•BLOCKING TABLE • 
•••*••••••••**•*• 



E3 *. 

••EITHER *. 
YES .* SYSUT1 OR « 

*.SYSUT2 TO BE 

*. TCLOSED .« 

*. .» 

*• •* 



• • 

• TCLOSE THE * 
->*INDICATED DATA * 

•CONTROL BLOCKS * 

• • 
**•••*#*••**•*#** 

•••• 



•••••F 2 ********** 
•SIORTN 11D2* 
*—•—•—•—«—•—•—•—• 

* ISSUE CHECK *- 

♦ FOR • 

• SYSUT1/SYSUT2 « 
•*••••••*•••••••* 



t F4 *-> 
t * 
• ••• v 
.*. 
F4 *. 
.* IS •• 
.» NEXT ». YES 

►. COMPONENT .• 

».AN INTER-.* 
••LUDE .* 
*. •* 
* NO 



»*#**F5* ********* 

•OBTAIN NAME OF * 

♦NEXT PHASE FROM* 

->* BLDL TABLEt * 

* AND MODIFY • 

• XCTL MACRO * 
••••**••••*••••** 



•••♦*G5«»* ••••*•# 

* EXAMINE RESET * 
•TABLE AND RESET* 

* RECORD COUNT « 

* FOR CHAINED * 
•OUTPUT BUFFERS » 
••***••••*•*•*••» 



****H5*** ****** 

i i 

* NEXT PHASE * 

t i 

•••**•*•••***** 
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Chart 20. Phase 5 (IEJFCAAO) Overall Logic 



• PHASE 1 * 

* ( IE JFAABO ) « 
» (SEE NOTE) « 

••••••••»»•*»•• 



•START 

• PHASE 
•INITIALIZATION 



SEE TABLE 3 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE S ROUTINE/ 
SUBROUTINE. 



PHASE 5 IS ENTERED FROM 
PHASE I CIEJFAAAO) FOR 
THE FIRST COMPILATION 
IN A BATCH. PHASE S 
IS EXECUTED FOR EACH 
SOURCE MODULE IN A 
BATCH SPACE RUN. IT 
IS EXECUTED ONLY FOR 
THE FIRST SOURCE MODULE 
IN A BATCH PRFRM RUN. 



•••••C 1 •••••••••• 

•GETSTRG » 
•—•—*-*—»-»—»-*-» 

• OBTAIN • 

• MAIN • 

• STORAGE • 



•••• 

.*. 

Dl ». 

•• MAIN ». 

LESS .STORAGE OBT.*. 

-••VERSUS AMOUNT. 

••REQUESTED.* 

». •• 

•• •* 



•••••D2«»»»»»»»»« 

• » 

• FREE • 
>• EXCESS MAIN • 

• STORAGE • 



•—•—•-•-•-•-•-•—a 

• READ AND PRO- • 
•CESS ANY PATCH • 

• RECORDS » 

•••••••••••••»••• 



*-*-•-*-*-»- 



••••••••••••••••* 



•—•—•-•-•-•-•-•-• 

• ALLOCATE MAIN • 
•STORAGE FOR I/O* 

• TEXT BUFFERS * 

*•••••••••••••••• 



*»»»*D5»»»»»»»»** 
•GETOANDO * 
*—*—*-*-*—*-*-*-* 
• ALLOCATE MAIN • 
•STORAGE FOR OCT* 
•AND OVFLOW TBL • 
••••*•••••••••••* 



». I/O BLOCKED 



•••• 

• • 

• AS • 

• • 
•••• 



»**»»E3*»»»»»**»» 
•OCBEXAM • 

•-•-•-•-•-•-»-•-• 
->• ALLOCATE MAIN • 
•STRG TO BLOCKED* 
• I/O BUFFERS • 



.» MAIN STRG •• 

•OBTAINED VERSUS* 

•• MINIMUM .» GREATER OR 
REQUIRED* EQUAL 



• 


ENOUGH ». 


YES 


• 




MAIN STORAGE . 


» 


->» 


A5 




LEFT .* 




• 






»• •• 




•••• 




• • •• 










• NO 









»*»»*G2*»*»»**»** 

•FREEALL • 

»—»—»-•-*_»-»-»-» 

->• FREE ALL MAIN • 

• STORAGE • 

* OBTAINED • 



CHAINALL V 

••••*F5********** 
» ALLOCATE RE- • 
•MAINDER OF MAIN* 

• STORAGE TO * 

• CHAINEO TEXT • 

• BUFFERS • 
••••••••••••*•••• 



***»G3»**»***»» 

• * 

• PHASE 1 • 

• (IEJFAAB0) • 



•••••HI **•****••• 

• MINCORE • 

• UNCONDITIONAL 

• GETMAIN FOR 
•MINIMUM AMOUNT 

••••••••••••••••• 



n 



•****H2 **••**••** 

• ALTER • 

• PRFRM • 
•COMPILATION TO » 
» SPACE • 

• COMPILATION • 
••••••••••••••••a 



••••J2»»»»»»«»» 
» PHASE 1 * 
* (IEJFAA80) * 



•-•—•-*—•-•-*-•-• 

• FREE ANY * 

• UNUSED MAIN • 

• STORAGE * 

••••••••••••••••a 



•***HS********* 
» * 

» PHASE 7 * 
» (IEJFEAAO) « 

•••••••••••a*** 
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Table 3. Phase 5 Main Routine/Subroutine Directory 

Function 



r t- 

| Routine/Subroutine | 



h 



| ALLOCATE 

| ALLOC 40 
CHAINALL 

|DCBEXAM 

FREEALL 
| GETDANDO 
GETIOBFS 
GETSTRG 
MESSGOUT 
| MINCORE 

PATCH 
START 



Interpolates (using the allocation table) the amount of main storage 
| to be allocated to the dictionary, overflow table, and text buffers. 

| Completes the construction of SEGMAL (begun in GETSTRG). 

[Allocates remainder of obtained main storage to text buffer chains 
(for PRFRM compilations only) . 

j Determines the DCBs that have been opened, and allocates main 
storage to special block/deblock I/O buffers for those data sets for 
| which blocking is specified. 

[Frees any unusable main storage. 

Allocates main storage to the dictionary and the overflow table. 
| Allocates main storage to the four I/O text buffers. 

Obtains main storage for the compiler. 

| Writes messages on SYSPRINT. 

| Obtains minimum amount of main storage required for a SPACE 
compilation. 

[Builds patch table by reading and then converting patch records. 

Performs Phase 5 initialization. 
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Chart 30. Phase 7 (IEJFEAAO) Overall Logic 



••••A3********* 

• PHASE 1 OR • 

• PHASE S « 

• (SEE NOTE) « 



»****B3 »****»*»»» 

• • 

• MOVE • 
•OVERFLOW INDEX • 

• INTO PLACE • 

• • 
••••••••••••••••• 



••»»»C3»»»»«»»»»« 

* • 

* INITIALIZE * 

* FOVFLNXT. AND * 

* FDICTBLK * 

* * 
•••***•*••••••*•• 



***»*D3*» •»••**•• 
•MOVE DICTIONARY* 

* INDEX AND RE- * 

* SERVED WORD * 
•PORTION OF DICT* 

* INTO PLACE » 
••••••••••••••**• 



***»*E3****««***« 

* • 

* INITIALIZE * 

* FDICTNDX, • 

* FDICTNXTt AND * 

* FOVFBLK • 
*•••*••••••••*•** 



•EJECT SYSPRINT • 
•TO NEW PAGE AND* 

• PRINT HEADING * 

• * 
•••••*••••*••**•• 



— PHASE 
PHASE 

PRFRM COMPILATIONS OTHER 
THAN FIRST. FROM PHASE 
(IEJFCAAO) FOR SPACE 
COMPILATIONS OR FIRST 
PRFRM COMPILATION IN A 
BATCH. 



.* SPACE •• 

•• OR PRFRM • 
*. COMPILATION 



.FIRST COMPILE. 

. OF A BATCH . 

•COMPILATION* 



•••••H3********** 

• • 

•DELETE PHASE 5 • 

• • 

• # 
••••••*••••••*••• 



.•ADJUST *• 
.•OR NOADJUST*. 
. OPTION IN 
». EFFECT .* 



NOADJUST 



*»*»K2 *»***»*»* 
» • 

► PHASE 8 < 
» (IEJFFAAO) * 

•••••*•*•••••*• 



PHASE 10D 
( IEJFGAAO) 
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Chart 40. Phase 8 (IEJFFAAO) Overall Logic 



•••••A2*<******** 



• PHASE 7 

• (IEJFEAAO) 



SEE TABLE 4 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 8 ROUTINE. 



READ CARD 

IMAGE INTO 

INPUT BUFFER 



•*»»*B3»»»»**»»** 
» • 

* MOVE CARD • 

» IMAGE TO » 
» PRIMARY WORK * 
» AREA * 



SOURCE 
OPTION IN 
. EFFECT 



••***C4 *»##»#»»#* 

* WRITE OUT * 

* CONTENTS OF * 
>* INPUT BUFFER ON» 

« SYSPRINT * 

* # 
•»»»»»»*»•*»»»»»# 



»»»»»03«»*»»»**»* NOTE - 
» « 

•SCAN CARD IMAGE* 

* FOR NAMES AND » 

* DELIMITERS * 



THE TRT INSTRUCTION 
IS USED TO SCAN EACH 
CARD IMAGE OF THE 
SOURCE MODULE. 



»**»*E2*» ******** 

* MOVE PACKED * 
•SEGMENT OF CARD* 
♦IMAGE TO INTER-*<- 

* MEDIATE WORK * 

* AREA * 
»*»»*»•»»»»»»»»»» 



»*»#»E3********** NOTE 

* PACK NAME AND • 

* ASSOCIATED * 
-* DELIMITER * 

* (ELIMINATE * 

* BLANKS) * 
»**••»*••••••***• 



IF FORMAT STATEMENT. 
DO NOT PACK H OR 
QUOTE FIELDS. 



.* ANY *. 

.•KEYWORDS IN*. 

». PACKED . 

*. SEGMENT .* 



»»»»»F3»»»******* 

• INSERT * 

• SPECIAL * 
»* CHARACTERS * 

•WHERE NECESSARY* 

• » 
*•»•••••••••••••* 



••THIS FIRST 

*. CARD IMAGE 

*.FOR STMT . 



•••••H4 ********** 
•DELETE SPECIAL ♦ 
♦CHARACTER FROM * 
->* KEYWORD WHICH * 
•DEFINES STATE- * 
• MENT TYPE * 
*•**•••••*•••*»** 



•••••J2*»******** 
•MOVE CARD IMAGE* 
•TO OUTPUT BFR, * 
•INSERT REQUIRED*- 
« MEANINGFUL * 
• BLANKS • 
•••••••••••*••••• 



****«j 3* •»••*•••• 

* • 
•WRITE CONTENTS • 

>* OF OUTPUT *- 

* BUFFER ON * 

* SYSUT2 • 
*•••*•*•••••***** 



.* LAST *. 
STATEMENT 
OF SOURCE 

. MODULE . . 



******** 
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Table 4. Phase 8 Routine/Subroutine Directory 



j Routine/Subroutine j 



Function 



BROOT j Branch table for delimiters that may appear in a FORTRAN statement. 

DOOUT (Initializes move of DO statement to output area. 

ENDCARD j Checks for the END statement. 

ENDCOMP (Performs final Phase 8 processing when an END statement is encoun- 

jtered. 

FINDEND (Moves remaining characters of statement to output area. 

FMTEST | Tests for a possible FORMAT statement. 

GET (Obtains next card image to be processed. 

HMOVE | Moves Hollerith fields in FORMAT statements from input area to work 

(area. 

LBLSCN | Scans and packs statement numbers, and moves packed statement 

(numbers to output buffer. 

OUT (Determines statement type and initializes for output. 

ODTMODl (Moves statement control words to output area. 

PACKSCAN | Begins processing of each statement. 

PHASE8 | Performs Phase 8 initialization. 

PRINT1 | Prints source module listing on the SYSPRINT data set if the SOURCE 

(option is in effect. 

POT (Writes input for Phases 10D and 10E on SYSUT2. 

RESUME j Performs initialization to resume statement processing after part of 

| a statement has been processed. 

SCAN | Scans and packs segments of card images, and moves packed segments 

| from primary work area to intermediate work area. 

SCAN3 (Identifies reserved words. 

SEARCH3 I Checks for reserved words embedded within statement. 

SSCAN (Identifies and determines length of Hollerith fields in FORMAT 

I statements . 



H 
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Chart 50. Phase 10D (IEJFGAAO) Overall Logic 



NOTE — PHASE 10D IS ENTERED FROM 
PHASE 7 (IEJFEAAO) IF THE 
NOADJUST OPTION IS IN 
EFFECT. FROM PHASE 8 
(IEJFFAAO) IF THE AOJUST 
OPTION IS IN EFFECT. 



***«A3»******»* 
» PHASE 7 OR * 
* PHASE 8 * 

► ( SEE NOTE ) * 



SEE TABLE 6 FOR A BRIEF 
DESCRIPTION OF THE 
FUNCTION OF EACH PHASE 10D 
ROUT I NE/SU8ROUT I NE . 



•»#»*B3** **»»•*♦• 
» START » 

* PHASE * 
•INITIALIZATION * 



»*#»**»#*•»»»»»*» 



»»»##C 3 ******♦»♦• 

* • 

* OBTAIN A * 
» SOURCE MODULE * 

* STATEMENT * 

* * 



»»#*#D3 •*»***#### 
•ENTER STATEMENT* 
•ON SYSPRINT IF • 
•SOURCE AND NO- • 
•ADJUST OPTIONS • 
* ARE IN EFFECT • 
••*••••••••#•*••• 



#»#*»E3*******»** 

• CLASS • 
*—#—#—#—•—♦—#—*—# 

• DETERMINE • 

• STATEMENT • 

• TYPE • 
•*•••*#•••••*••** 



F3 *. 
.* *« 
.» SF OR 
*. EXECUTABLE 
•. 



#»*##G3»*«#»»»«»» 

• • 

• • PROCESS • 
» SOURCE *< 

• STATEMENT * 

• • 
•*•*#*••••••••••• 



****F4 ••••••••• 

# 4 
->* PHASE 10E * 

* (IEJFJAAO) * 



»«***G4 ********** 

* EOSR * 

->* CHECK FOR * 

* END-OF- • 

* STATEMENT * 

***************** 



SEE TABLE 5 FOR A LIST 

OF THE STATEMENTS PROCESSED 

BY PHASE 10D AND THE MAIN 

ROUTINES AND SUBROUTINES 

THAT PROCESS THESE 

STATEMENTS. 



6U 



Table 5. Phase 10D Statement Processing 



r 

(Statement Type 


|Main Processing Routine | 


Main Subroutines Used 3 


|REAL | REAL/ INTGER/DOUBLE 
,. + 

j INTEGER j REAL/ INTGER/DOUBLE 
J + 

| DOUBLE PRECISION j REAL/ INTGER/DOUBLE 


X 

x 
x 


1 
1 

H 

1 

H 

1 
i 


Control is passed to DIM 


| DIMENSION 


T 

j DIM 
i _ 


X 


i 

1 
i 


GETWD, RCOMA, CSORN, DIMSUB, WARN/ERRET 


| COMMON 


| COMMON 

1 

i_ 


X 
2 


1 

1 

1 
i 


DIM 


(EQUIVALENCE 
L__ 


| EQUIV 

1 

_ i _. 


X 
2 


T 
1 

1 

I 


GETWD, CSORN, WARN/ERRET, RCOMA 


| EXTERNAL 


| EXTERN 
_ i._ _ 


1 


1 

I 


GETWD, RCOMA, CSORN 


| FUNCTION 
| SUBROUTINE 


j FUNCT 

1 
__ + 

| SUBRUT 

1 

_ i _ _ _ 


X 
2 

X 
2 


1 
1 

H 

1 

1 
i 


GETWD, CSORN, PUTX 


| FORMAT 


| FORMAT 
_ i_ _ _ 


2 


1 


GETWD, WARN/ERRET, PUTX 


| DEFINE FILE 


| DEFINE 

1 
_ J. 


X 
2 


1 

1 
i 


GETWD, CSORN, PUTX 


| l Table entries may be prepared when processing this statement. 

| a Text is created when processing this statement. 

j 3 All routines except FORMAT use ERROR as an error exit for errors that cause termina- 

( tion of the statement processing FORMAT has no error exit. 
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Table 6. Phase 10D Main Routine/Subroutine Directory 

Function 



r t" 

| Routine/Subroutine | 



I" 



H 



CLASS 

COMMON 
CSORN 

DEFINE 
DIM 

DIMSUB 

EOSR 
ERROR 

EQUIV 

EXTERN 

FORMAT 

FUNCT 

GETWD 

INTGER/REAL/DOUBLE 
LABLU 

LABTLU 
LITCON 
LOADE 
PRMBLD 

PUTX 

RCOMA 

START 

SOB RUT 

SYMTLU 

WARN/ERRET 



Determines which routine will process the statement type. 
LOADE and LABLU. 

Processes COMMON statements. 



May use 



Processes names, constants, data set reference numbers, and DO 
parameters. May use LITCON and SYMTLU. 

Processes DEFINE FILE statements. 

Processes the variables of DIMENSION, COMMON, INTEGER, REAL, and 
DOUBLE PRECISION statements. 

Scans the subscript portion of a statement that is dimensioning an 
array. 

Processes the end of statement. 

Enters error intermediate text for errors that cause termination of 
the processing of that statement. 

Processes EQUIVALENCE statements. 

Processes EXTERNAL statements. 

Processes FORMAT statements. 

Processes the header card image for a FUNCTION subprogram. 

Obtains a word or element in a statement and gets a new card image, 
if necessary. Prints the card if SOURCE option requested. May use 
PRMBLD. 

Processes INTEGER, REAL, and DOUBLE PRECISION statements. 

Enters only statement number information into the overflow table. 
Uses LABTLU. 

Enters all information into the overflow table. 

Processes literals. 

Performs end-of-phase processing and passes control to Phase 10E. 

Performs all operations associated with I/O interfacing and buffer 
switching. 

Puts entries into the SYSUT1 text buffers. 

Enables skipping of redundant commas in a parameter list. 

Performs initial phase housekeeping. 

Processes the header card for a SUBROUTINE subprogram. 

Enters symbols and/or units into the dictionary. 

Enters warning and error intermediate text for error and warning 
conditions that permit the continuation of the processing of the 
statement. 
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Chart 60. Phase 10 E (IEJFJAAO) Overall Logic 



•***A3********* 

* 4 

* PHASE 10D * 
» (IEJFGAAO) « 

*••***•••*•*•** 



#****B3********** 
» START » 
*—*—*—»—*—*—*_*_* 
* PHASE * 
•INITIALIZATION * 



SEE TABLE 8 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE IOE ROUTINE/ 
SUBROUTINE. 



**•****••*••***** 



*****C3********** 

* * 
♦OBTAIN A SOURCE* 

* MODULE * 

* STATEMENT ♦ 

* * 
••*••••*•*•***••* 



#****D3********** 
♦ENTER STATEMENT* 
♦ON SYSPRINT IF ♦ 
♦SOURCE AND NO- ♦ 
♦ADJUST OPTIONS ♦ 
♦ARE IN EFFECT ♦ 
*•***•***••***•** 



*****E3 ********** 

♦ CLASS ♦ 

*—*—*_*_*_*—*_*_* 

♦ DETERMINE ♦ 

♦ STATEMENT ♦ 

♦ TYPE ♦ 

*••**•••*••*•*•** 



END *. YES 
STATEMENT .♦ 



*****G3**#******* 

♦ • 

♦ ♦ PROCESS ♦ 

♦ SOURCE ♦< 

♦ STATEMENT ♦ 

♦ * 



*****F4********** 

* END ♦ 
*—*—*—*—*—*—*—*-* 

->* PROCESS *- 

* END * 

* STATEMENT ♦ 

**•**••••****•**« 



*****G4********** 

♦ EOSR * 

*_*_*—*_*_*_*—*_* 

->* CHECK FOR ♦ 

♦ END-OF- ♦ 

♦ STATEMENT ♦ 

***************** 



*****F 5* ********* 

* EXIT * 
*-*-*-*_*-*-*-*-* 

->*PERFORMS FINAL * 
» PHASE IOE * 

* PROCESSING * 



#*»*H4 ********* 

* * 

* INTERLUDE IOE *<- 

* (IEJFJGAO) * 
***#•••*•#*•*** 



.*. 

H5 *. 

.* SPACE *. 
SPACE .* OR PRFRM * 
*. COMPILATION 



*• 



♦PRFRM 



SEE TABLE 7 FOR A LIST OF 
THE STATEMENTS PROCESSED 
BY PHASE IOE AND THE 
MAIN ROUTINES AND SUB- 
ROUTINES THAT PROCESS 
THESE STATEMENTS. 



••••j 5* ******** 

t i 

* PHASE 12 « 

* (IEJFLAAO) * 

*************** 
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Table 7. Phase 10E Statement Processing 



r t t- 

| Statement Type | Main Processing Routine | 



Main Subroutines Used 3 



ARITHMETIC 



ARITH 



* JCSORN, PUTX, GETWD, SUBS (ARITH may pass control 
2 jto ASF, DO, and GO) 



SF 



ASF 



*■ JCSORN, GETWD 

2 I 



CALL 



CALL 



1 | PUTX, GETWD, CSORN (exits to ARITH) 

2 I 



DO 



DO 



1 | ARITH, CSORN, GETWD, LABLU, PUTX 

2 I 



GO TO 



COMP GO TO 



GO 



1 I 

2 I 



GO 



.J ARITH, GETWD, LABLU, PUTX, CSORN, WARN/ERRET 

X I 

2 I 



IF 



SUBIF 



* | GO, PUTX (exits to ARITH) 
2 i 



READ 



WRITE 



FIND 



BACKSPACE 



REWIND 



ENDFILE 



READ/WRITE/FIND 



READ/WRITE/ FIND 



H GETWD, CSORN, PUTX, LABLU (exits to ARITH) 



READ/WRITE/FIND 



FORMAT 


+ 

| FORMAT 
_i _ 


2 


j GETWD, WARN/ERRET, PUTX 
_x _ _ _ _ 


CONT 


| CONT/RETURN 
_x _ 


2 


T 

1 

-J GFTWD WARN/FRRFT PTITX 


RETURN 


T 

| CONT/RETURN 
- 4- — - 


2 


1 

_4- _ _ _ _ _ 


STOP 


T 

j STOP/PAUSE 
_x _ _ 


2 


T 

1 
-4 GETWD PUTX (f»vits to CTjASS) 


PAUSE 


— T 
| STOP/PAUSE 
+ 


2 


1 
_ + 



BKSP/ 



REWIND/ 



ENDFIL 



1 JCSORN, GETWD, PUTX 

2 I 



^Table entries may be prepared when processing this statement. 
2 Text is created when processing this statement. 

3 A11 routines except FORMAT and CONT/RETURN use ERROR as an error exit for errors 
that cause termination of the statement processing. 
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Table 8. Phase 10E Main Routine/Subroutine Directory 



j Routine/Subroutine 



Function 



ARITH 

ASF 

BKSP/REWIND/ENDFIL 

CALL 

CLASS 

CONT/RETURN 

CSORN 

DO 
END 
EOSR 
ERROR 

EXIT 

FORMAT 

GETWD 

GO 

LABLU 

LABTLU 
LITCON 
PRMBLD 

PUTX 

READ/WRITE/FIND 

START 

STOP/PAUSE 

SUB IF 

SUBS 

SYMTLU 

WARN/ERRET 



Processes arithmetic statements. May use SUBS. 

Processes the parameter list of a statement function. 

Processes the BACKSPACE, REWIND, and ENDFILE statements. 

Processes the name of a CALL statement. 

Determines which routine will process the statement type. 

Processes CONTINUE and RETURN statements. 

Processes names, constants, data set reference numbers, and DO 
parameters. May use LITCON and SYMTLU. 

Processes the DO statement and implied DOs. 

Processes the END statement. 

Processes the end of the statement. 

Enters error text into the intermediate text and terminates the 
processing of current statement. 

Performs end-of -phase processing. 

Processes FORMAT statements. 

Obtains a word or element in a statement and gets a new card 
image, if necessary. Prints the card if SOURCE option is 
requested. May use PRMBLD. 

Processes the statement number branched to by an IF, GO TO, or 
computed GO TO statement. 

Enters only statement number information into the overflow 
table. Uses LABTLU. 

Enters all information into the overflow table. 

Processes literals. 

Performs all operations associated with I/O interfacing and 
buffer switching. 

Puts entries into the intermediate text buffers. 

Processes the portion of the statement preceding the I/O list. 

Performs Phase 10E initialization. 

Processes the STOP and PAUSE statements. 

Begins the IF statement processing. 

Processes subscript variables. 

Enters symbols and/or units into the dictionary. 

Processes warning and error conditions that do not prevent 
completion of the processing of the current statement. 
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Chart 70. Phase 12 (IEJFLAAO) Overall Logic 



»***A2********* 
» PHASE 10E OR * 
» INTERLUDE 10E « 
» (SEE NOTE) « 

*************** 



SEE TABLE 9 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 12 ROUTINE/ 
SUBROUTINE. 



PHASE 12 IS ENTERED FROM 
PHASE 10E (IEJFJAAO) FOR 
PRFRM COMPILATIONS! OR FROM 
INTERLUDE 10E (IEJFJGAO) 
FOR SPACE COMPILATIONS. 



.*—#—#—#_ 



**************** 



-*—*—*—«. 



•INITIALIZES FOR*<- 
* EQUIVALENCE * 
•TXT PROCESSING » 



* 


»*»*C2 »***»*»**» 


« 


COMALO 


* 








* 


ASSIGN ADDR. 


TO* 


* 


/AR. AND ARRAYS* 


* 


IN COMMON 




• 


ft*************** 



COMALO USES THE 
ALOWRN/ALERET. 
SORSYM*». GETCOMI, 
AND GETCOM SUBROUTINES 



• PROCESSES * 

• EQUIVALENCE * 

• TEXT « 

*****#****»****#* 



EQUIVP USES THE 
EQUS02, EQUS03. 
AND EQUS14 
SUBROUTINES 



• INCR. LOCATION * 
•CNTR BY SIZE OF* 

* COMMON » 
•ft*************** 



EXTCOM USES THE 

ALOWRN/ALERET 

SUBROUTINE 



*—*—*—*—*—*—*—*—* 

* ASGN ADDR TO * 

* DBL-PREC VAR, « 
•ARRAYS IN DICT.l 

******»****«***»« 



DPALOC USE THE 
INTDCT. EQSRCH. 
SORSYM**t AND 
DELETE SUBROUTINES 



» ASGN ADDR TO 
* REAL AND INT 
•VAR AND ARRAYS 

*******»•»»«***« 



SALO USES THE 
INTDCT, EQSRCH, 
AND SORSYM** 
SUBROUTINES 



•ASGN ADDRESSES 

• TO EQUATED 

• VAR 

**************** 



ALOC USES THE 
INTDCT. ALOWRN/ 
ALERET, EQSRCH, 
AND DELETE SUB- 
ROUTINES 



*-»**«jl #*#»*« 



• PROC DICT ENT • 
•FOR EXT AND IN • 
•LINE FUNCTIONS • 

»»*****»*»»»***** 



LDCN USES THE 
INTDCT, ESD*. 
DELETE. RLD*. 
AND GOFILE SUB- 
ROUTINES 



»**«J3*»*»**« 

* PHASE 14 

* (IEJFNAAO) 



•PREPARES BRANCH*- 
•LIST TABLE FOR • 
• REF STMT NOS. * 

••*•••••••••*•*•« 



*****K2********** 



->*REPL CHAIN FLO •- 
•FOR SUBSCRIPTED* 
» VAR WITH ADDR • 

***************** 



>» ASSIGN ADDR » 

• TO CONSTANTS * 

* IN DICTIONARY • 

***************** 



SORLIT USES THE 
TXT*. ESD*. 
SORSYM**, GOFILE, 
AND RLD* SUBROUTINES 
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Table 9. Phase 12 Main Routine/Subroutine Directory 

Function 



r t- 

| Routine/Subroutine | 



h 



ALOC 

ALOWRN/ALERET 
ASGNBL 
COMALO 

DELETE 
DP ALOC 

EQINIT 

EQSRCH 

EQUIVP 

EQUS02 

EQUS03 

EQUS14 

ESD 

EXTCOM 

GETCOM/ GETEQ UI V 

GETCOMI 

GOFILE 

INTDCT 

LDCN 

RENTER/ENTR 

RLD 

SALO 

SORLIT 

SORSYM 

SSCK 

STARTA 
SWROOT 
TXT 



Assigns addresses to all equated variables. 

Processes the error and warning conditions detected in Phase 12. 

Allocates a branch list position for each referenced stmt, number. 

Assigns addresses for variables or arrays to be placed in COMMON and 
removes these variables from the appropriate dictionary chain. 

Removes dictionary entries from chain. 

Assigns addresses to all double-precision variables or arrays 
entered in the dictionary. 

Performs initialization for equivalence text processing. 

Checks for variables previously equated to a root. 

Performs equivalence text processing. 

Processes first name in an EQUIVALENCE group. 

Processes rest of EQUIVALENCE group and switches root if necessary. 

Processes all equated variables and arrays in COMMON. 

Processes ESD card images. 

Enters size of COMMON in comm. area, and adjusts location counter. 

Updates COMMON or EQUIVALENCE text pointer, reads in text records. 

Initializes pointers and I/O parameters for COMMON-EQUIVALENCE text. 

Generates card images for data sets SYSLIN and/or SYSPUNCH. 

Retrieves entries from the dictionary. 

Processes dictionary entries for functions and external references. 
Also prepares ESD section definition card images for the object 
module and COMMON areas. 

Enters variables in the EQUIVALENCE table either as a root or as an 
equated variable. 

Processes RLD card images. 

Assigns addresses to real and integer variables and arrays. 

Assigns addresses and generates text card images for all literals 
(constants) ; performs the final processing of the phase. 

Arranges and prints the storage map for all arrays, constants, and 
external references assigned addresses by Phase 12. 

Replaces pointers to variables used in subscript expressions with 
addresses assigned by Phase 12. 

Initializes Phase 12. 

Changes a root previously entered. 

Processes TXT card images. 
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Chart 80. Phase 14 (IEJFNAAO) Overall Logic 



****A2 ********* 

» i 

* PHASE 12 * 

* (IEJFLAAO) * 
*************** 



SEE TABLE 12 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 14 ROUTINE/ 
SUBROUTINE. 



*****B2** ******** 

* PHINIT * 
*_#_*_*_*_*—*-*—* 

* PHASE * 
•INITIALIZATION * 



***************** 



**** 



•****C2** ******** 

* PRESCN * 
*—•—*—•—*—*—•—*—* 

* OBTAIN STATE- * 

* MENT AND DE- * 

* TERMINE TYPE * 
***************** 



.*. 

02 *. 
>* *. 

END *. > 
STATEMENT .*- 

.* 
*. .* 
*. .* 
* NO 



*****D3********** 

* END * 
*—*—•—*—*—*—*—*—* 

->* PERFORMS *- 
♦FINAL PHASE 14 * 

* PROCESSING * 
*••***•••******** 



04 *. 

.* SPACE *. 
.* OR PRFRM *. PRFRM 

->*. COMPILATION .* 

*• .* 

*• .* 

*. .* 
•SPACE 



****D 5* ******** 

* t 
->* PHASE 15 < 

* (IEJFPAAO) * 

*************** 



.* FORMAT 
f. STATEMENT 
*. 

*. •* 

*. .* 
* NO 



*****F2 ********** 



* PROCESS 
STATEMENT 



»****E3 ********** 

* FORMAT * 
*—*—*—*—*—•—*—*—* 

->* ** PROCESS * 

* FORMAT * 

* STATEMENT * 
*•**•***••****•** 



*****E4»* ******** 

* * 

* DELETE MAIN * 

* STORAGE *- 

* OCCUPIED BY * 

* DICTIONARY * 
*•••*••••******** 



FORMAT USES THE 
CKENDO, GETWDA, 
INTCON. AND MSG/ 
MSGMEM SUBROUTINES 



#***E5*****##** 

* t 
->* INTERLUDE 14 * 

* (IEJFNGAO) * 

*************** 



***************** 



SEE TABLE 10 FOR A LIST 
OF THE STATEMENTS PROCESSED 
BY PHASE 14 AND THE ROUTINES 
AND SUBROUTINES THAT PROCESS 
THESE STATEMENTS. 



** SEE TABLE 11 FOR A LIST 
OF THE FORMAT CODES THAT 
MAY APPEAR IN A FORMAT 
STATEMENT AND THE SUB- 
ROUTINES THAT PROCESS 
THESE CODES. 
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Table 10. Phase 14 Statement Processing (FORMAT 

r t 

Statement Type | Main Processing Routine 
+ 

FORMAT | FORMAT 



Statements Excluded) 
— t 



Main Subroutines Used 



Refer to Table 11 



WRITE 



READ 



READWR 
READ 



UNITCK, ERROR, MSGMEM 



+~ 



SUBROUTINE 



FUNCTION 



SUBFUN 
SUBFUN 



RDPOTA S MSGMEM, RPTRB 



CONTINUE 



SKIP 

BSPREF 

BSPREF 



MSGMEM 



BACKSPACE 



REWIND 



ENDFILE 



UNITCK, MSGMEM 



BSPREF 

DO 

LABEL 



DO 



CKENDO, ERROR, MSGMEM, RDPOTA 1 
None 



STATEMENT | 
NUMBER I 



SF 



ASF 
RETURN 



PAS SON, CEM, RPTRB 
CKENDO, MSGMEM, SKIP 



RETURN 



STOP 



STOP 
PAUSE 



CKENDO, SKIP 

CKENDO, SKIP, RDPOTA * 

None 



PAUSE 



INVALID 



INVOP 

ERWNEM 



ERROR 



WARNING 



None 



ERWNEM 
MSG 



END MARK 



None 



IF 



ARITH 



CALL 



GO TO 



PASSON 
PAS SON 



PASSON 
PASSON 



CEM 



COMP GO TO 



CGOTO 
COMEQUIV 



CKENDO, RDPOTA, MSG, MSGMEM 



COMMON 



EQUIVALENCE 



None 



COMEQUIV 
PASSON 



DEFINE FILE 



CEM 



^Replaces dictionary point* 
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Table 11. Phase 14 FORMAT Statement Processing 



j FORMAT Code j Main Subroutine Used j 
,. + 4, 

j blank j BLANK Z j 

L __ _ _ _ _ J. _ _ _ _ J 


r — T — — 1 

| D j FMDCON | 
L _, _ _ _ _ _ J. _ _ _ _ _ _J 


r — r 1 

| E | FMECON | 
L _ _ _ _ J. _ _ _ _ _ _ J 


r — --- - - — f - - - — ____ _.| 
| F | FMFCON | 
L _ _ _ J. _____ J 


r T _____ ^ 
j I j FMTINT j 
L _ _ _ _ _J. _ _ _ _ J 


r t — 1 
| A | FMACON | 
L_ _ _ J. _ _ _ _ J 


j X | FMXCON | 
L _ _ _ _ 4. _ _ _ ___ 4 


r — __^.___ ___ .j 

| P | FSCALE j 
L _ 4. _ _ _ _ J 


r — T — 1 

j + | FMPLUS | 
L _ ___ 4. _ _ _ __ 4 


r — ___ ^._ _ _ __ .j 
j - | FMINUS | 

j ( j LPAREN j 

| / j FSLASH j 
L - _4._ __4 


r T 1 

j T | FSUBST | 

L _ _i _ _ _ _J 


| H | FHOLER | 
^ 4, ^ 

j • | FQUOTE | 
L_ __ _ 4._____ _ 4 


r — - — — — -j.___ _ _^ 
j , | FCOMMA | 

j ) j RPAREN j 
L__ ___ J.__ _ 4 


Table 12. Phase 14 Main Routine/Subroutine Directory 


r — ~~ ~t~ ~~ ~ ~ — ~ ~ ~ i 

| Routine/Subroutine | Function | 

L + ^ 



ASF 

BLANK Z 

BSPREF 

CEM/RDPOTA/RPTRB 

CGOTO 

CKENDO 

COMEQUIV 

DO 

END 

ERROR 

ERWNEM 



Processes the SF definition text. 

Processes any blanks encountered while scanning a FORMAT statement. 

Processes BACKSPACE, REWIND, and ENDFILE statement text. 

Completes text processing for arithmetic, BACKSPACE, REWIND, END- 
FILE, GO TO, DO, CALL, IF, PAUSE, and SF definition statements. 

Processes text for computed GO TO statements. 

Determines if a statement has invalidly ended a DO loop. 

Deletes COMMON and EQUIVALENCE text from intermediate text. 

Performs diagnostic checks on the DO variable and the DO parameter. 

Processes END text. 

Generates intermediate text for errors detected in Phase 14. 

Processes error and warning text. 

J 

(Continued) 
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Table 12. Phase 14 Main Routine/Subroutine Directory (Continued) 

Function 



r t- 

| Routine/Subroutine | 



H 



FCOMMA 

FHOLER 

FMACON 

FMDCON 

FMECON 

FMFCON 

FMINUS 

FMPLUS 

FMTINT 

FMXCON 

FORMAT 

FQOOTE 

FSCALE 

FSLASH 

FSUBST 

GETWDA 

INTCON 

INVOP 

LABEL 

LPAREN 

MSG/MSGMEM 

PAS SON 

PAUSE 

PHINIT 

PRESCN 

READ/READWR 

RETURN 

RPAREN 

SKIP 

STOP 

SUBFUN 

UNITCK 



Processes any commas found in a FORMAT statement. 

Processes the H specification in a FORMAT statement. 

Processes the A specification in a FORMAT statement. 

Processes the D specification in a FORMAT statement. 

Processes the E specification in a FORMAT statement. 

Processes the F specification in a FORMAT statement. 

Processes the • -' specification in a FORMAT statement. 

Processes the *+' specification in a FORMAT statement. 

Processes the T specification in a FORMAT statement. 

Processes the X specification in a FORMAT statement. 

Performs and directs some FORMAT processing. May use INTCON. 

Processes the apostrophe specification in a FORMAT statement. 

Processes the P specification in a FORMAT statement. 

Processes the slash format specification in a FORMAT statement. 

Processes the T specification in a FORMAT statement. 

Scans FORMAT statements. 

Converts integer constants to binary and checks their validity. 

Processes invalid adjective codes. 

Processes statement number definition text. 

Processes left parentheses. 

Inserts error/warning messages into text and detects end of stmt. 

Processes CALL, IF, and arithmetic IF statement text. 

Processes PAUSE statement text. 

Performs phase initialization. 

Performs phase initialization and controls processing of int. text 

Processes READ/WRITE text. 

Processes RETURN statement text. 

Processes any right parenthesis occurring in a FORMAT statement. 

Processes CONTINUE statement text. 

Processes STOP statement text. 

Processes SUBROUTINE and FUNCTION text entries. 

Checks validity of symbols used to reference a DSRN. 
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Chart 90. Phase 15 (IEJFPAAO) Overall Logic 



****A3********» 

* PHASE 14 OR * 

* INTERLUDE 14 * 

* ( SEE NOTE ) * 
*************** 



* B3 »-> 



**** 

*****B3* ********* 

* PRESCN * 
*—*—*—*—*-*—*—*—* 

* OBTAIN STATE- * 
•MENT AND DETER-* 
*MINE STMT TYPE * 
***************** 



SEE TABLE 15 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 15 ROUTINE/ 
SUBROUTINE. 

NOTE 

PHASE 15 IS ENTERED FROM 
PHASE 14 (IEJFNAAO) FOR 
PRFRM COMPILATIONS. OR 
FROM INTERLUDE 14( (IEJFNGAO) 
FOR SPACE COMPILATIONS. 



*****D2 ********** 



* PROCESS 
STATEMENT 



***************** 



END *. YES 
STATEMENT .* 



* No 



D3 *. 

NO .** CAN "*« 

*.STMT CONTAIN , 

*. ARITH .* 
*.EXPR .* 



*****C4 ********** 

* MOPUP * 
*—*—*—*—*—*-•—*-* 

->* PERFORMS *- 
•FINAL PHASE 15 * 

* PROCESSING * 
***************** 



*****D4 ********** 

* FOSCAN ** * 
*—*—*—*—*—*—*—*-* 

->* CONTROLS THE * 

* REORDER AND * 
♦MOD OF INT TXT * 
•**********••**•* 



****C 5* ******** 

* * 

* INTERLUDE 15 * 

* (IEJFPGAO) * 
*************** 

A 



D5 *. 

.* SPACE *. 
.* OR PRFRM *. 
->*. COMPILATION ,i 
*. .* 

*. .* 



*****E3********** 
MSGNEM/MSGMEM/MSG * 
*—*-*—*—*-*—*—*—* 
— >* PROC REM OF *<- 
•STMT AND FORMS * 
*E/W TXT IF NEC * 
***************** 



****E5********* 
t i 

* PHASE 20 * 

* (IEJFRAAOJ * 
*•••******•**** 



SEE TABLE 13 FOR A LIST 
OF THE NONARITHMETIC 
STATEMENTS PROCESSED BY 
PHASE 15 AND THE MAIN 
ROUTINES AND SUBROUTINES 
THAT PROCESS THESE STATEMENTS. 



** FOSCAN PROCESSES ARITHMETIC, 

ARITHMETIC IF. STATEMENT FUNCTION 
AND CALL STATEMENTS. SEE TABLE 14 
FOR A LIST OF THE OPERATORS THAT MAY 
APPEAR IN THE ABOVE STATEMENTS AND 
THE MAIN ROUTINES AND SUBROUTINES 
THAT PROCESS THESE OPERATORS. 
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Table 13. Phase 15 Nonarithmetic Statement Processing 



J Statement 


Type or 


Adjective 


Cd | 
4-- 


Main Processing 


Routine 1 


±_ 


Main Subroutines Used | 


| COMPUTED GO TO 






T 

1 
— 4— 


CGOTO 








T 
. 4— 


LAB, CEM | 


| DEFINE FILE 






T 

1 
4— 


DEFNFL 








T 


None j 


| DO 








T 

1 

— 4— 


DO 








T 
. 4— 


LABI, CEM | 


| END MARK 








T 
1 


MSG 








T 
-4— 


None j 


| ERROR 








T 

1 

4._ 


ERWNEM 








— r 


None j 


| GOTO 








T 

1 
— 4— 


GOTO 








T 
. 4— 


LAB, CEM | 


| INVALID 








T 

1 

— — 4— 


INVOP 








T 
i 


ERROR | 


| I/O LIST 








T 

1 

x_ 


BEGIO 








t 
J. 


MSGMEM | 


| STATEMENT 


NUMBER 






— T 
1 

L_ 


LABEL 








T 


ERROR | 


| WARNING 








1 


ERWNEM 








j 


None | 


| READ/WRITE 






T 
1 
— 4-- 


DO 2 








T 
X 


CEM | 


| RETURN/CONTINUE 






T 
1 


SKIP 








T 


None j 


| ^-Routine MSGNEM/MSGMEM/MSG 
| These two routines return 


is entered from all 
control directly to 


these routines 
PRESCN. 


except ERWNEM and LABEL. | 
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Table 14 
r 



Phase 15 Arithmetic Operator Processing 



T - T 

| Main Processing | 
Operator | Routine | Main Subroutines Used 
+ + 

ADD | ADD | FREER, SAVER % SYMBOL, MODE, MVSBXX, FINDR, 
| | LOADR1 
+ + 

ARGUMENT j COMMA | CKARG, ERROR, WARN, SAVER 1 , INLIN2, INARG, 
| j MSGMEM 
. _ ___J.___ J. _ 


■ r — -— -(- — -— — 

CALL FORCING | CALL | MSG 
+ + 

DIVIDE | MULT | SYMBOL, MODE, LOADRl, CHCKGR *■ , SAVER *-, 
| j FREER, DIV, MVSBXR, MVSBXX 

+ + 

EQUAL j EQUALS | ERROR, TYPE, MODE, MVSBRX, WARN, MVSBXR, 
j j ASFDEF 
+ + 

EXPONENTIATION | EXPON | SYMBOL, MODE, CKARG 
1 + 

FUNCTION ( j FUNC j CKARG, INLINl 
___J._«_ J. _ __ 


— -__ T T 

ILLEGAL j INVOP | ERROR 
+ + 

LEFT PAREN j LFTPRN j CKARG, ERROR, ARTHIF, WARN, LOADRl 

J._ ___-L ____ __. 


_ .j— ___-(. ____ __. 

MULTIPLY | MULT | SYMBOL, MODE, MVSBXX, LOADRl, CHCKGR * , FREER 
+ + 

RIGHT PAREN | RTPRN | ERROR 
+ + 

SUBTRACT j ADD | SYMBOL, MODE, MVSBXX, FINDR, LOADRl, FREER, 
j | SAVER *■ 
+ + 

UNARY MINUS | UMINUS | TYPE, FINDR, LOADRl, MVSBRX, INVOP 
1 + 

UNARY PLUS j UPLUS j INVOP 

_ J. _ _ _ X _ _ ___. 


^-Specific sections of the SAVER and CHCKGR routines operate upon specific registers 
(general registers 0, 1, 2, 3; floating point register 0, 2, 4, 6). 
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Table 15. Phase 15 Main Routine/Subroutine Directory 



j Routine/Subroutine j 
I" 



Function 



ADD 

ARTHIF 

ASFDEF 

BEGIO 

CALL 

CEM 

CHCKGR 

CKARG 

COMMA 

CGOTO 

DEFNFL 

DIV 

DO 

D02 

END 

EQUALS 

ERROR 

ERWNEM 

EXPON 

FINDR 

FOSCAN 

FREER 

FUNC 

GOTO 

INARG 

INLIN1 

INLIN2 

INVOP 

LAB 



Determines register assignment for add, subtract, multiply, and 
divide operators. 

Processes the statement numbers of an arithmetic IF statement. 

Processes statement function definitions. 

Processes the I/O list of READ and WRITE statements. 

Processes CALL statements. 

Checks for an end mark. 

Obtains a specific general register for assignment. 

Checks the argument in an external call for validity, and ensures 
that the argument has a storage location. 

Processes the argument lists. 

Processes the statement numbers in a computed GO TO statement. 

Processes DEFINE FILE statements. 

Processes integer operands of a divide operation. 

Processes DO statements. 

Writes out a text word if not an end mark. 

Determines if the arithmetic IF, arithmetic, and SF statements were 
processed. 

Processes equal adjective code text. 

Processes error conditions detected in the phase. 

Processes end mark, error, and warning text. 

Processes exponentiation text. 

Finds a register and indicates that it is a register. 

Checks the syntax of arithmetic, arithmetic IF, CALL, and SF 
statements, and orders the arithmetic expression text according to a 
hierarchy of operators. Uses END. 

Indicates a register is available. 

Processes one-argument functions. 

Processes statement numbers referenced by a GO TO statement. 

Processes the argument of an in-line function. 

Processes one-argument, in-line functions. 

Processes two-argument, in-line functions. 

Processes invalid adjective codes. 

Checks for illegal statement number references. 

j 

(Continued) 
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Table 15. Phase 15 Main Routine/Subroutine Directory (Continued) 

Function 



r t - 

| Routine/Subroutine | 



h 



LAB1 

LABEL 

LFTPRN 

L0ADR1 

MODE 

MOPUP 

MSGNEM/MSGMEM/MSG 

MULT 

MVSBXR/MVSBRX 

MVSBXX 

PRESCN 

RTPRN 
SAVER 

SKIP 

SYMBOL 

TYPE 

UMINUS 

UPLUS 

WARN 



Checks whether label is defined. 

Checks statement numbers used to indicate the end of a DO loop. 

Process the text for a left parenthesis. 

Enters an operand into a specific register. 

Checks the mode of operands and changes them if necessary. 

Performs final phase processing for Phase 15. 

Processes the remaining text words of a statement and puts out any 
necessary error, warning, and end do text. 

Aids in processing the operands of multiply and divide instructions. 

Processes a left operand subscripted variable. 

Processes a left operand subscripted variable if the right operand 
might also be a subscripted variable. 

Determines what statement type is represented in the text and which 
major routine will process it. 

Processes illegal use of right parenthesis as a delimiter. 

Stores the contents of a specified register into the next available 
work area space. 

Processes RETURN and CONTINUE statements. 

Checks the left and right operands of an operator. 

Checks each symbol used as an operand. 

Processes unary minus operations. 

Processes unary plus operations. 

Processes warning conditions detected in the phase. 
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Chart AO. Phase 20 (IEJFRAAO) Overall Logic 



NOTE 

PHASE 20 IS ENTERED 
FROM PHASE 15 (IEJFPAAO) 
FOR PRFRM COMPILATIONS. 
OR FROM INTERLUDE IS 
(IEJFPGAO) FOR SPACE 
COMPILATIONS. 



****A3********* 

* PHASE 15 OR * 

* INTERLUDE 15 * 

* ( SEE NOTE ) * 

*************** 



SEE TABLE 18 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 20 ROUTINE/ 
SUBROUTINE. 



•****B3 ********** 

* INIT * 
*-*_*_*-*—*-*-*-* 
» PHASE * 

* INITILIZATION * 

* * 
***************** 



• *** | 
V 
*****C3********** 

* STATA * 

♦OBTAIN STMT AND* 
♦DETERMINE STMT * 

* TYPE * 

***************** 



D3 



*. 



*****E2 •*•**•*••* 



* PROCESS 
STATEMENT 



•••**•**•»****••• 



.* END *. YES 

*. STATEMENT .* 

*• •* 

*• .* 
*. .* 
* NO 



E3 *. 

• * *. 
NO .* CAN *. YES 

*.STMT CONTAIN .* 

♦.SUBSCRIPT.* 

*.EXPR .* 

*. .* 



*****B4** ******** 

* PHEND * 
*-*—*-*-*—*—*-*-* 

->*PERFORMS FINAL * 

* PHASE 20 PRO- * 

* CESSING * 
***************** 



C4 *. 

.* ANY 
SOURCE 
MODULE 
. ERRORS 
*. 



****C5*****^^*« 
t i 

* PHASE 25 * 

* (IEJFVAAO) i 
*************** 



04 *. 
.* IS *. 

.* "LOAD* *. NO 

*. OPTION IN .* 

*. EFFECT .* 
*. .* 



**if'0 5*** ****** 

* i 
->* PHASE 30 < 

* (IEJFXAAO) i 

*************** 



L 



->* C5 * 

* * 
**** 

*****E4********** 

* * 

* ** PROCESS * 
->* STATEMENT * 

* * 

* • 
***************** 



SEE TABLE 16 FOR A LIST OF- 1) 

THE STATEMENTS PROCESSED BY PHASE 20 

THAT DO NOT CONTAIN SUBSCRIPT EXPRESSIONS. 

AND 2) THE MAIN ROUTINES AND SUBROUTINES 

THAT PROCESS THESE STATEMENTS. 



** SEE TABLE 17 FOR A LIST OF l) 

THE STATEMENTS PROCESSED BY PHASE 
20 THAT MAY CONTAIN SUBSCRIPT EXPRESSIONS, 
AND- 2) THE MAIN ROUTINES AND SUB- 
ROUTINES THAT PROCESS THESE STATEMENTS. 
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Table 16. Phase 20 Nonsubscript Optimization Processing 















| Statement Type 


1 

— +— 


Main Processing 


Routine 


-+- 


Main Subroutines Used 


| DO 


1 

4. 


DO 




4. . 


BVLSR, RMVBVL 




T 






— T 




| END DO 


1 


ENDDO 




-+- 


None 


| IMPLIED DO 


1 

L 


IOLIST 




- 4- - 


BVLSR, CALSEQ, RMVBVL, SUBVP 




— r 






T 




| READ 


1 

JL 


READ 




- 4. - 


None 




r 






T 




| STATEMENT 


1 


LABEL 






None 


| NUMBER 


1 











Table 17. Phase 20 Subscript Optimization Processing 



Statement Type 
ARITHMETIC * 



Main Processing Routine j 
+- 



ARITH 



Main Subroutines Used 
CALSEQ, CKCOD, RMVBVL, SUBVP 



CALL *■ 
I 

IF ± 
| 

I/O *■ 



+~ 



IFCALL 
IFCALL 
IOLIST 



BVLSR, CALSEQ, RMVBVL, SUBVP 



None 



| BVLSR, CALSEQ, RMVBVL, SUBVP 



i. ± 

^-Whenever exponentiation is encountered subroutine ESDRLD processes the exponentiation 
operands. 
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Table 18. Phase 20 Main Routine/ Subroutine Directory 

Function 



r t- 

| Routine/Subroutine | 



h 



|ARITH 
I BVLSR 
CALSEQ 
CKCOD 

JDO 

[DUMPR 
ENDDO 
ESDRLD 

| GENGEN 
IFCALL 

INIT 
IOLIST 

LABEL 
|PHEND 
| READ 
IRMVBVL 

STATA 

i SUBVP 



| Optimizes arithmetic statement text. 

I Enters bound variables on the bound variable list. 

Processes argument lists. 

| Assigns an area and a constant for use by the IFIX, FLOAT, and 
|DFLOAT in-line functions. 

| Processes DO statements. 

Processes dummy subscripted variables. 
| Ensures that the end of a DO loop is recognized. 
| Generates ESD and RLD card images. 

Begins the generation of literals. 

j Optimizes the arithmetic expression of an arithmetic IF statement or 
a CALL statement. 

Performs Phase 20 initialization. 

[Processes DO variables of an implied DO and I/O lists of READ/WRITE 
j statements . 

j Modifies register assignments due to referenced statement numbers. 

| Performs final Phase 20 processing. 

Processes external references within a READ statement. 

| Removes register assignments from the index mapping table for 
(subscript expressions that involve bound variables. 

| Checks the statement type represented by the text and determines the 
correct Phase 20 processing routine. 

[Optimizes subscript expressions. 
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Chart BO. Phase 25 (IEJFVAAO) Overall Logic 



**** A3 ********* 
» « 

► PHASE 20 * 
i ( IEJFRAAO) * 

*************** 



SEE TABLE 20 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 25 ROUTINE/ 
SUBROUTINE. 



*****B3********** 

* START * 
*—*—*—•—*—*—*—*—* 

* PHASE * 
•INITIALIZATION * 

* * 
***************** 



C3 *. 
.* IS *. 

.* OBJECT *. YES 

*LI STING OPTN IN* 

*. EFFECT .* 
*. .* 
*. .* 
* NO 



*****C4 ********** 

* • 

* LOAD OBJECT * 
->*LISTING MODULE * 

* (IEJFVCAO) * 

* • 
***************** 



PRESCN V 

*****03 ********** 

* OBTAIN TEXT * 

* WORD AND * 

* DETERMINE * 
♦ADJECTIVE CODE * 

* OR STMT. TYPE * 
A**************** 



E3 *. 

.* *, 

t END 
STATEMENT 



•****F3********** 

* * 

* * PROCESS * 

* STATEMENT OR * 
•ADJECTIVE CODE • 

* * 
*»*»•••****•«»•** 



•****04 ********** 

* END • 
*—*—*—*—*—*-*-*—* 

->*PERFORMS FINAL • 

* PHASE 25 * 

* PROCESSING * 
*••••******•**•*• 



****#E4********** 

* • 

* DELETE OBJECT * 
•LISTING MODULE • 

* IF IT WAS * 

* LOADED • 
*•••*•**•******•• 



****F4 ********* 
t * 

* PHASE 30 * 

^ (IEJFXAAO) * 

********•»•»*** 



SEE TABLE 19 FOR A LIST 
OF THE STATEMENTS AND 
ADJECTIVE CODES PROCESSED 
BY PHASE 25 AND THE MAIN 
ROUTINES AND SUBROUTINES 
THAT PROCESS THE STATEMENTS 
OR ADJECTIVE CODES. 
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Table 19. Phase 25 Statement and Adjective Code Processing 



| Statement or Operation 


|Main Processing 
_x 


Routine ** | Main Subroutines Used 

-L 




|AOP 






T — 

|AOP 

X 






| BASCHK 

4- - - 






|Arith expressions 
| approximate instr. 


in | RXGEN/LM/STM 
f ormj 

_X 






T 

j BASCHK/RROUT , 

j. 


RXOUT 




|SF DEFINITION 






|ASFDEF 1 

— i 






| LISTOUTB 
4. _ 






|SF USAGE 






| AS FUSE 
—I 






— T 

j BASCHK/RROUT, 
4. 


RXOUT 




| BACKSPACE 






T 

|RDWRT 
-X 






T 

| BASCHK, ARGOUT, GET, RXOUT 
i _ _ 




|CALL 






T 

j FUNGEN 
_X _ _ 






| BASCHK/RROUT 
4. _ _ _ 






| COMPUTED GOTO 






T 

| CGOTO 

_i _ 






T 

j BASCHK/RROUT , 
4. _ _ 


ARGOUT 




|D0 






|D01 
_X _ _ 






T 

j BASCHK, RXOUT 

X — 






|END DO 






T 

| ENDDO 
_X _ _ 






T 

j BASCHK, RXOUT 
4. 






|END FILE 






| RDWRT 
_x _ _ 






— T 

(BASCHK, ARGOUT, RXOUT, GET 
4. _ _ 




|END I/O LIST 






T 

j ENDIO 
-4- — 






T 

| RXOUT 
4. 






| ERROR 






T 

| IBERR 

4- - - 






— T 

j BASCHK, RROUT 
i _ 






| FUNCTION 






T 

|SUBRUT 2 
_4. _ _ _ 






|GENBR, GET, RROUT, RXOUT 
4. _ 




| FUNCTION CALL 






T 

j FUNGEN 
-4- 






T 

J BASCHK/RROUT, 
i _ 


RXOUT 




|G0 TO 






T 

j TRGEN 
_x _ _ . 






| BASCHK/RROUT, 
i_ _ 


RXOUT 




| IF 






|ARITHI 

— f 






| BASCHK/RROUT 
i 






| IMPLIED DO 






|D01 
_x _ _ . 






| BASCHK, RXOUT, 
4__ _ 


LISTOUTB 




|I/0 LIST ITEM 






T 

j IOLIST 
-4- - 






— T - — 

| ARGOUT, BASCHK/RROUT, RXOUT 
-4- — 




| LABEL 






T 

| LABEL 3 
_4- _ _ 






T 

| LISTOUTl 
4. _ 






|LOAD MULTIPLE 






T 
|LM 

_x _ _ . 






T — 

j BASCHK/RROUT, 

i _ 


RXOUT 




| PAUSE 






| PAUSE 
_x . 






| BASCHK/RROUT, 
_ 4_ 


RXOUT 




| READ/WRITE/FIND 






T — 
| RDWRT 
_4._ 






T — 
| BASCHK/RROUT , 
4- 


ARGOUT, RXOUT 




| RETURN 






T — 
| RETURN 
_i _ _ _ _ 






T 

| BASCHK/RROUT, 
4. _ 


RXOUT, LISTOUTl 




| REWIND 






| RDWRT 
_i _ _ 






T — 

j BASCHK, ARGOUT, RXOUT 
_4. _ _ __ 




|STOP 






|STOP 
4. 






— ~T 

|None 

X 






| STORE MULTIPLE 






T 

|STM 
_i _ . 






T 

| BASCHK/RROUT, 
x_ _ _ __ 


RXOUT 




| SUBROUTINE 






|SUBRUT a 

_i _ 






T 

JGENBR, BASCHK/RROUT, RXOUT 
X — 




| SUBSCRIPT 






|SAOP 






T 

j BASCHK/RROUT, 

X 


RXOUT 




j 1 Makes an entry in 
| 2 Makes an entry in 
| 3 Makes an entry in 
|*»All of the above 
| processing of the 


the statement function and DO branch list table 
the epilog table. 

the statement number branch list table, 
routines return control to the PRESCN routine to 
next text word. 


begin the 





L J 
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Table 20. Phase 25 Main Routine/Subroutine Directory 



| Routine/Subroutine 



Function 



AOP 

ARGOUT 

ARITHI 

ASFDEF 

ASFUSE 

BASCHK/RROUT, RXOUT 

CGOTO 

DOl 

END 

ENDDO 

ENDIO 

FUNGEN/IBERR 

GENBR 

GET 

IOLIST 

LABEL 

LISTOUTB/LISTOUT1 

PRESCN 

RDWRT 

RETURN 
RXGEN/LM/STM 

SAOP 

START 
STOP/PAUSE 
SUBRUT 
TRGEN 



Processes subscript text when the entire subscript expression need 
not be calculated. 

Inserts addresses for arguments into the object module. 

Processes arithmetic IF statements. 

Processes the first text word of a statement function definition. 

Generates instructions to use a statement function at object time. 

Generates RX and RR format instructions. 

Processes computed GO TO statement text. 

Begins processing of the DO statement text. 

Performs the final Phase 25 processing. 

Generates instructions to end a DO loop. 

Processes the end I/O text. 

Processes in-line and library function calls. 

Makes entries to the branch list tables. 

Obtains intermediate text words. 

Processes the I/O list substatement text. 

Processes statement number definition text entries. 

Generates branch list text. 

Determines which routine will process a particular portion of 
intermediate text. 

Processes READ, WRITE, FIND, BACKSPACE, REWIND, and ENDFILE 
statements. 

Processes RETURN statement text. 

Processes intermediate text entries with adjective codes between 
25 and 8F (hexadecimal). 

Processes subscript text when the entire subscript ordering factor 
must be calculated. 

Performs phase initialization. 

Generates instructions for the STOP and PAUSE statement text. 

Processes FUNCTION and SUBROUTINE header card text. 

Generates branching instructions for GO TO statements. 
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Chart CO. Phase 30 (IEJFXAAO) Overall Logic 



NOTE 

PHASE 30 IS ENTERED FROM 
PHASE 20 (IEJFRAAO) IF THE 
NOLOAD OPTION IS IN EFFECT 
AND IF SOURCE MODULE ERRORS 
WERE DETECTED t OTHERWISE, 
PHASE 30 IS ENTERED FROM 
PHASE 25 (IEJFVAAO). 



***»A2»* ******* 
» PHASE 20 OR * 

• PHASE 25 * 

* (SEE NOTE) « 
••••••A******** 



SEE TABLE 21 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH PHASE 30 ROUTINE/ 
SUBROUTINE. 



NO .*ANY ERRORS *. 




i *. OR WARNINGS .* 




». .» 




1 *. .* 




V *. .* 




**** * YES 




* • 






* G2 * 






* * 






• ••• 






V 




•****C2 ********** 




•THIRTY * 


INCTXT 
TXTIN 


* PRIME * 


* TEXT * 




* BUFFERS * 




*******»4 


********* 





-*-*-*< > PRINT 



»•••••**•••*» 



**** 

* » 

* G2 *-> 



PHASE 25 



*—»—*—*—*—*—*—*—* 
•PRIMES TEXT BFR» 
* COMPUTES SIZE * 
*OF BR LIST TBLS» 

***************** 



*—*—*—*—»-*_*—*_ 
• BUILDS AN IN- 
TERNAL TBL FOR 
•BR LIST TABLES 

**************** 



*GEN TXT AND RLD* 
•CARD IMAGES FOR* 
*BR LIST TABLES • 
»»**»***********• 



• GENERATE TXT * 
•CARD IMAGES FOR* 
•BASE VALUE TBL » 

***************** 



NXTOUT 

ENDTXT<- 

ANYRLD 



-> TXTOUT 



* GENERATE RLD 
•CARD IMAGES FOR* 
♦BASE VALUE TBL * 

•••*••••**••**•*• 



* GENERATE END * 
•CARD IMAGE FOR * 

• OBJECT MODULE • 

•••••••••••••***• 



-•< > TXTOUT 



•PHASE 20 



SUBROUTINE ENDCRD 
ALSO SETS UP THE 
•SIZE OF COMMON 
AND SIZE OF PROGRAM* 
MESSAGE. 



••*»H2 ********* 
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Table 21. Phase 30 Main Routine/Subroutine Directory 

r r 

| Routine/Subroutine | 



Function 



ANYRLD 
BASRLD 
CHKLBL 
ENDCRD 

ENDTXT 

ERR/WARN 

GENTAB 

INCTXT 

NXTOUT 

PRINT 

THIRTY 

TWNFIV 

TXTIN 

TXTOUT 

ZRTXT 



Generates RID card images for branch list tables. 

Generates RLD card images for base value table. 

Controls generation of TXT and RLD card images for branch lists. 

Generates END card image for object module, and sets up 'SIZE OF 
COMMON and SIZE OF PROGRAM' message. 

Switches input/output buffers. 

Sets up error and warning messages. 

Builds an internal table for branch list tables. 

Increments intermediate text pointer. 

Generates TXT card images for branch list tables. 

Interfaces with control program to print messages. 

Primes input text buffers. 

Primes input text buffers. 

Reads intermediate text. 

Outputs card images on SYSLIN and/or SYSPUNCH data sets. 

Generates TXT card images for base value table. 



APPENDIX A: MAIN STORAGE ALLOCATION 



The amount of main storage allocated to 
the compiler depends on whether a SPACE or 
a PRFRM compilation is being performed. 



FOR SPACE COMPILATIONS 



contiguous only for each control section. 
Figures 16 through 22 reflect the main 
storage allocation associated with each 
successive phase/interlude as it performs 
its functions, when only a minimal amount 
of storage (15K bytes, where K = 1024) is 
available for compilation. 



For SPACE compilations, the compiler 
requires main storage for: 

• Load modules (phases, interludes, and 
interface) . 

• Resident tables (dictionary, overflow 
table, SEGMAL) . 

• Internal text buffers. 

• BSAM I/O routines and control blocks. 

The main storage required by each 
phase/ interlude of the compiler need be 



When the main storage allocated to the 
compiler (specified in the SIZE option) is 
greater than 15K bytes, the internal text 
buffers may be interspersed within the area 
occupied by the dictionary and the overflow 
table. In this case, there need be no 
relationship between the various areas 
required by the compiler. 



These figures are schematics showing the 
main storage allocated; proportional sizes 
within the diagrams do not necessarily 
indicate proportional amounts of main stor- 
age. 



32K, 



INTERFACE MODULE 



17K|- 



BSAM ROUTINES 



PHASE 5 



AVAILABLE MAIN 
STORAGE 



PHASE 1 



RESIDENT 

CONTROL 

PROGRAM 



L 

Figure 16. 



32K, 



INTERFACE MODULE 



32K, 



h~ 



I" 
■j 17K|- 



BSAM ROUTINES 



PHASE 5 



AVAILABLE MAIN 
STORAGE 



PHASE 1 



OVERFLOW TABLE, SEGMAL 



4 INTERNAL TEXT BUFFERS 



RESIDENT 

CONTROL 

PROGRAM 



| INTERFACE MODULE 

j. 

BSAM ROUTINES 

j. 

PHASE 5 



1 17Kh 



AVAILABLE MAIN 
STORAGE 


TRANSIENT WORK t 


&REA 


DICTIONARY 


OVERFLOW TABLE, 


SEGMAL 


4 INTERNAL TEXT 


BUFFERS 



Main Storage at 
the End of Phase 1 
(initial entry) 



l J o «- 

Figure 17. Main Storage at Figure 18 

the End of Phase 1 

(subsequent 

entries) 



RESIDENT 

CONTROL 

PROGRAM 



J 



Main Storage at 
the End of 
Phase 5 
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32K 



INTERFACE MODULE 



17K 



| BSAM ROUTINES J 


| TRANSIENT WORK 


AREA | 


| PHASE 7, PHASE 8, | 
| PHASE 10D, PHASE 10E, | 
I INTERLUDE 10E | 

| DICTIONARY | 


| OVERFLOW TABLE, 
| 4 INTERNAL TEXT 


SEGMAL | 
BUFFERS | 


| RESIDENT 
| CONTROL 
| PROGRAM 





«■- 
Figure 19. 



Main Storage at the End of 
Phases 7, 8, 10D, and 10E; 
and Interlude 10E 



32K r t 

I 

|. ., 



17K 



INTERFACE 


MODULE 


BSAM ROUTINES 


TRANSIENT 


WORK AREA 


PHASE 12, 
INTERLUDE 


PHASE 

14 


14, 


DICTIONARY 


OVERFLOW TABLE, 


SEGMAL 


4 INTERNAL TEXT 


BUFFERS 



RESIDENT 

CONTROL 

PROGRAM 



L J 

Figure 20. Main Storage at the End 
of Phases 12 and 14, and 
Interlude 14 



32K r 
h 



17K 



INTERFACE MODULE 
BSAM ROUTINES 
TRANSIENT WORK AREA 



32K 



PHASE 15, 
INTERLUDE 15 



OVERFLOW TABLE, SEGMAL 



4 INTERNAL TEXT BUFFERS 



RESIDENT 

CONTROL 

PROGRAM 



L J 

Figure 21. Main Storage at the End of 
Phase 15 and Interlude 15 



17K 



INTERFACE MODULE 



BSAM ROUTINES 



TRANSIENT WORK AREA 



PHASE 20", 
PHASE 25, 
PHASE 30 



OVERFLOW TABLE, SEGMAL 
4 INTERNAL TEXT BUFFERS 



RESIDENT 

CONTROL 

PROGRAM 



L J 

Figure 22. Main Storage at the End 
of Phases 20, 25, and 30 
(on entry to Phase 1) 
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FOR PRFRM COMPILATIONS 36K, 



For PRFRM compilations, the compiler 
requires main storage for: 



y- 



• Load modules (phases, interface, and 
performance) . 

• Resident tables (dictionary, overflow 
table, and SEGMAL). 

• Internal text buffer chains. 

• BSAM I/O routines. 

• Block/deblock buffers if blocking is 
specified. 

The main storage required by any given 
phase of the compiler need be contiguous 
only for each control section within that 
phase. Figure 23 reflects the main storage 
allocation for the duration of a PRFRM 
compilation, when only a minimal amount of 
main storage (19K bytes, where K=1024) is 
available for compilation. 

When the main storage allocated to the 
compiler (specified in the SIZE option) is 
greater than 19K bytes, the internal text 17K 
buffers may be interspersed within the area 
occupied by the dictionary and the overflow 
table. In this case, there need be no 
relationship among the various areas 
required by the compiler. 

Figure 23 is a schematic showing the 

main storage allocated; proportional sizes L 

within the diagram do not necessarily indi- Figure 23. 
cate proportional amounts of main storage. 



INTERFACE MODULE 



PERFORMANCE MODULE 



BSAM ROUTINES 



TRANSIENT WORK AREA 



PHASE 1, PHASE 5, 
PHASE 7 , PHASE 8, 
PHASE 10D, PHASE 10E, 
PHASE 12, PHASE 14, 
PHASE 15, PHASE 20, 
PHASE 25, OR PHASE 30 



DICTIONARY, OVERFLOW 
TABLE, AND SEGMAL 



4 INTERNAL TEXT BUFFER CHAINS 



BLOCK/DEBLOCK BUFFERS (IF 
BLOCKING IS SPECIFIED) 



RESIDENT 

CONTROL 

PROGRAM 



Main Storage Allocation for a 
PRFRM Compilation 



Appendix A: Main Storage Allocation 91 



APPENDIX B: COMMON ICAT ION AREA (FCOMM) 



The communication area is a central 
gathering area used to communicate neces- 
sary information between the various phases 
of the compiler. The communication area, 
as a portion of the interface module, is 
resident throughout the compilation. 



Several entries in the communication 
area are equated to the addresses of other 
entries in the communication area used 
during earlier phases. Equating the 
entries keeps the size of the communication 
area to a minimum. 



Various bits in the communication area 
are examined by the phases of the compiler. 
The status of these bits determines such 
things as: 



Options specified by 
grammer . 



the source pro- 



• Specific action to be taken by a phase. 



The communication area is assembled as a 
DSECT (dummy section) within each phase. 
This allows the phases to symbolically 
address the entries in the communication 
area without the communication area actual- 
ly residing in each phase. 

Table 22 indicates the format and organ- 
ization of the communication area. 



Table 22. Communication Area 
r t t 



| Entry 

L J 


Size 


j. 


Meaning 


r — - 1 


r ~ ~ 






j FCOMM 


DS XL4 


JBITO 


SOURCE 1 






JBIT1 


DECK * 






|BIT2 


MAP 1 






| BIT3 


ADJUST 1 






JBIT4 


PRFRM ± 






| BITS 5-6 


00 NOLOAD ± 
11 LOAD x 






|BIT7 


BCD x 






| BIT8 


NAME PARAMETER EXISTED 






JBITS 9-10 


00 MAIN PROGRAM 

10 SUBROUTINE SUBPROGRAM 

11 FUNCTION SUBPROGRAM 






jBITll 


FUNCTION NAME DEFINED 






JBIT12 


OBJECT MODULE CALLS AN EXTERNAL S/P 






JBIT13 


SPARE 






| BIT14 


LAST COMPILE OF THIS JOB STEP-PH 10E/1 






|BIT15 


ERROR ON ANY COMPILE OF A BATCH RUN 






JBIT16 


WARNING MESSAGES 






JBIT17 


ERROR MESSAGES 






JBIT18 


MESSAGE IN CURRENT STATEMENT-PH 10D/10E 
INPUT BUFFER TO BE PRIMED-PH 12/14 
•DIOCS' ESD TO BE GENERATED-PH 14/20 






| BIT19 


WARNING IN ANY COMPILE OF A BATCH RUN 






|BIT20 


ABORT COMPILATION 






JBIT21 


ALL INTERNAL TEXT IN STORAGE 






JBIT22 


ONE INTERNAL TEXT RECORD-PH 10D/10E 
OBJ. MOD. USES A SPILL BASE REG-PH 12/25 
BRANCH LIST TEXT NOT ALL IN STORAGE-PH 25/30 






|BIT23 


OBJECT LISTING 






|BIT24 


OTHER THAN FIRST COMPILE 






|BIT25 


COMPILATION RESTARTED 






JBIT26 


INVALID OPTION (S) IN 'PARM* FIELD 






| BIT27 


•NAME' OPTION TOO LONG-TRUNCATED 






JBITS 28-31 


SPARE 



(Continued) 
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Table 22. Communication Area (Continued) 
r t t 



j Entry j 
L — 4- 


Size 

j 


Meaning 

L_ _ _ _ _ 


r t 


1 


r 


JFSIZE |DS 


F 


BYTES OF STORAGE REQUESTED FOR COMPILER * 


| FDATE | DS 


CL5 


YEAR (2 DIGITS), DAY (3 DIGITS) 


JFLINELNGJDS 


X 


OBJECT PROGRAM PRINT LINE LENGTH ± 


JFINDEX |DS 


H 


DISPLACEMENT FROM FCOMM TO FDECBIN 


j FMAXLINE | DS 


H 


MAXIMUM NUMBER OF LINES ON LISTING PAGE 


| FCURLINE | DS 


H 


CURRENT LINE ON LISTING PAGE 


JFIEJF |DS 


CL4 


FORTRAN E INTERNAL COMPONENT CODE - IEJF 


| FPHASE | DS 


CH 


ENTRY POINT OF PHASE IN CONTROL 


j FDMRRDCD j DS 


X 


HI-ORDER BYTE OF REREAD ITEM IN CLOSE LIST 


j FDMLSTCD | DS 


X 


HI-ORDER BYTE OF LAST ITEM IN CLOSE LIST 


j FPRTCTRL j DS 
L i. 


2H 

_ j 


BRANCH TO PRINT CONTROL ROUTINE 

L _ _ _ _ „ _ 


r 

j THE CONTENTS 


OF THE 


FOR SPACE | FOR PRFRM 


jNEXT 4 FIELDS DEPENDS 


COMPILATIONS | COMPILATIONS 


|ON WHETHER A 


SPACE OR A 


I 


|PRFRM COMPILATION IS 


I 


| BEING PERFORMED. 


I 


1— ■*■ - 




L _ _ J. _ _ 


r T 




r ~ T — - - 


| FIORTN j DS 


2H 


B SIORTN |MVI FPRFRMDL,X'4* 


j FNEXT j DS 


2H 


B SNEXT |L 13,FPRFRMDL 


1 l DS 


H 


(NOT USED) | BR 13 


|FPRFRMDL|DS 


A 


ZERO |ADDR. OF IEJFAPAO 


I. — — 4- 


- — -I 


l- — J- 


r T 


1 


r 


j FAGAOEND j DS 


A 


ADDRESS OF (END OF INTERFACE MODULE + ONE) 


|FSAVADDR|DS 


A 


ADDRESS OF CONTROL PROGRAM SAVE AREA 


|FTXBFSZA|DS 


H 


SIZE OF 'SYSUTl* INT. TEXT BUFFER 


|FTXBFSZB|DS 


H 


SIZE OF 'SYSUT2' INT. TEXT BUFFER 


|FTXTPTRA|DS 


H 


DISP. OF NEXT SYSUTl TEXT RCD.-PH 10D/10E, 12/14 


| FTXTPTRB | DS 


H 


DISP. OF NEXT SYSUT2 TEXT RCD.-PH 12/14 


IFTXTBFAIJDS 


A 


ADDRESS OF INTERNAL TEXT BUFFER 1 - SYSUTl 


j FTXTBFA2 j DS 


A 


ADDRESS OF INTERNAL TEXT BUFFER 2 - SYSUTl 


| FTXTBFB1 | DS 


A 


ADDRESS OF INTERNAL TEXT EUFFER 1 - SYSUT2 


|FTXTBFB2|DS 


A 


ADDRESS OF INTERNAL TEXT BUFFER 2 - SYSUT2 


| FPRTBUF1 | DS 


A 


ADDRESS OF FIRST PRINT BUFFER 


j FPRTBUF2 j DS 


A 


ADDRESS OF SECOND PRINT BUFFER 


| FINITBFS | DS 


4A 


INITIAL TEXT BUFFER POINTERS 


JFDICTNDXJDS 


A 


ADDRESS OF DICTIONARY INDEX - PHASE 7/12 


| FOVFLNDX | DS 


A 


ADDRESS OF OVERFLOW INDEX 


|FDICTBLK|DS 


A 


DICT. BLOCK NOW BEING BUILT - PH. 10D/E 


| FOVFLBLK | DS 


A 


OVFL. BLOCK NOW BEING BUILT - PH. 10D/E 


|FDICTNXT|DS 


A 


DICT. ENTRY NEXT TO BE BUILT - PH. 10D/E 


|FOVFLNXT|DS 


A 


OVFL. ENTRY NEXT TO BE BUILT - PH. 10D/14 


JFISNEX1 |DS 


F 


ISN OF FIRST EXECUTABLE- PHASE 10D/E 


|FOBJPROG|DS 


CL6 


NAME OF OBJECT PROGRAM 


| FOB JREGS | DS 


X 


BITS 0-2 SPARE 

BIT 3 EXTERNAL FUNCTION HAS BEEN CALLED 

BITS 4-7 LOWEST INDEX REGISTER IN OBJ. PROG. 


|FASFCNT |DS 


X 


COUNT OF SF'S IN OBJECT PROGRAM 


|FDOCOUNT|DS 


H 


NUMBER OF DO STATEMENTS 


1 l DS 


H 


SPARE 



(Continued) 
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Table 22. Communication Area (Continued) 



j Entry j 
h 



Size 



Meaning 



FCOMSIZE 

FALSIZE 

FBLSIZE 

FBLSTRT 

FASFDOBL 

FBVSTRT 

FOBJSTRT 

FLOCCTR 

FFNCADDR 

FIBCOM 

FOBJERR 

FDECKSEQ 

FESDSEQ 

FENDSTOR 

FALSTRT 

FDATEMP 

FDEFILCT 

FDIOCS 

FPATCH 

FPTCHTBL 

FPTCHPTR 

FSORSYM1 

FSORSYM2 



EQU FDICTBLK | SIZE OF OBJECT PROGRAM COMMON - PH. 12/30 

EQU FDICTBLK+2JSIZE OF OBJ. PROG. ARGUMENT LIST - PH. 15/20 

EQU FOVFLBLK |SIZE OF OBJ. PROG. BRANCH LIST - PH. 12/30 

EQU FOVFLBLK+2|ADDR. OF OBJ. PROG. BRANCH LIST - PH. 12/30 

EQU FOVFLNXT+2JADDRESS OF ASF/DO BRANCH LIST - PH. 20/30 

EQU FDICTNXT |ADDR. OF OBJ. PROG. BASE VAL. LIST - PH. 12/30 

EQU FDICTNXT+2 | STARTING ADDR. OF OBJECT PROGRAM - PH. 12/30 

EQU FISNEX1 | LOCATION COUNTER FOR OBJ. PROG. - PH. 12/30 

EQU FDICTBLK+2JADDRESS OF RESULT (FUNCTION S/P) - PH. 14/15 

EQU FOVFLNXT | ADDRESS OF IBCOM - PHASE 20/25 

EQU FDICTBLK+2JADDR. OF OBJ. PROG. ERROR RTNE. - PH. 20/25 

EQU FDICTNDX | OBJECT PROGRAM DECK SEQUENCE NUMBER'- PH. 12/30 

EQU FDICTNDX+2 | OBJECT PROGRAM ESD SEQUENCE NUMBER - PH. 12/20 

EQU FDICTNDX+2 | END-OF- DATA STORAGE ADDRESS - PH 25/30 

DS F |DSRN ARGUMENT LIST ADDRESS 

DS F j ADDRESS OF DIRECT ACCESS I/O TEMPORARY AREA 

DS F | 'DEFINE FILE' DSRN COUNT - PH. 10D/20 

EQU FDEFILCT | ADDRESS OF DIOCS - PH. 20/25 

DS 2H | BRANCH TO PATCH ROUTINE IN INTERFACE MODULE 

DS A j ADDRESS OF PATCH TABLE 

DS A | PATCH TABLE ENTRY NEXT TO BE POSTED 

DS A | ADDRESS OF SORSYM TABLE 

DS A | SORSYM TABLE ENTRY NEXT TO BE BUILT 



^Default values for these compiler options may be specified by the user during the 
system generation process via the FORTRAN macro-instruction. The default values 
specified at system generation time are assumed if the corresponding parameters in 
the PARM field of the user's EXEC statement are not included. 
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APPENDIX C: LINKAGES TO THE INTERFACE MODULE AND THE PERFORMANCE MODULE 



LINKAGE TO THE INTERFACE MODULE 



For SPACE compilations, the components 
of the compiler link to the interface 
module (IEJFAGAO) for input/output requests 
and end-of-phase/interlude requests. In 
addition, for both SPACE and PRFRM compila- 
tions, the compiler components link to the 
interface module for patch requests and for 
print control operations . 



Input/Output Request Linkage 



The linkage to the interface module for 
an I/O request is : 

L LNKREG,IOPARS 
BAL 15,FIORTN 

where : 

• LNKREG is general register 0. 

• IOPARS is the following 4-byte word: 

r t t 

| Operation | Address of the I/O buffer | 

j Field | For this operation | 
j. + i 

jl byte |3 bytes j 

l x J 

The operation field bits and their 
meanings are illustrated in Table 23. 



Table 23. Operation Field Bit Meanings 

r t 1 

| Bit | Check operation | 

j. + .j 

| Bit 1 (Read operation | 

h + 4 

| Bit 2 | Write operation | 

,. + 1 

| Bit 3 | Flush operation | 

y + 1 

JBit 4 j Not used j 

j. + 1 

j Bits 5-7 | 000 - SYSIN is to be used j 
| | 001 - SYSPUNCH is to be usedj 
| 1 010 - SYSLIN is to be used | 
j |011 - SYSUT1 is to be used | 
j j 100 - SYSUT2 is to be used j 
| | 101 - SYSPRINT is to be usedj 
j | 110 - Not used j 

j | 111 - Indicates that thej 
j j address of the DECB toj 
j j be used is supplied inj 
| | general register 1. j 
L j. j 



General register 15 contains the 
address of the instruction following 
the BAL instruction. 



• FIORTN is the name of a branch instruc- 
tion in the communication area that 
branches to the I/O routine (SIORTN) of 
the interface module. 



RETURNS : The SIORTN routine may return to 
the caller either normally or abnormally. 



Normal Return: The normal return is to the 



instruction 
instruction. 



that is 4 bytes beyond the BAL 



Abnormal Return: The abnormal return is to 
the instruction immediately following the 
BAL instruction. Two conditions may result 
in an abnormal return. They are: 

1. End-of-data set in which case general 
register 14 contains a zero. 

2. Permanent I/O error is which case 
general register 14 contains a four, 
and general register 1 contains the 
address of a save area for general 
registers 14, 15, 0, and 1. The save 
area has the following format: 

SYNADRET DS F 

SAVERET DS F 

IOPARS DS F 

DECBADDR DS F 

where : 

SYNADRET corresponds to general reg- 
ister 14 and contains the address to 
which control is to be passed if an 
I/O error is accepted and processing 
is to continue. 

SAVERET corresponds to general reg- 
ister 15 and contains the address of 
the instruction immediately following 
the BAL instruction. 

IOPARS corresponds to general register 
and contains the 4-byte word des- 
cribed previously in this section. 

DECBADDR corresponds to general reg- 
ister 1 and contains the address of 
the DECB associated with the data set 
for which the I/O operation was 
requested. 
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End-Of-Phase/Interlude Request Linkage 



where : 



The linkage to the interface module for 
an end-of-phase/interlude condition is: 



L 

BC 

where: 



LNKREG,NXPARS 
15,FNEXT 



• LNKREG is general register 0. 

• NXPARS is the following 4-byte word: 



r t 1 

| Entry point identifier |Data set | 
| of next phase/ interlude j disposition! 
| | field | 
,. + ^ 

| 3 bytes |1 byte | 

L JL J 

The data set disposition field bits and 
their meanings are illustrated in Table 
24. 



• WRKREG is general register 14. 

• BASEA contains the absolute address of 
relative location 0002 in the control 
section of the component to be tempo- 
rarily modified. 

• FPATCH is the name of a branch instruc- 
tion in the communication area that 
branches to the patch routine (PATCH) 
in the interface module. 

• * XX" is the fifth and sixth characters 
in the name of the component to be 
temporarily modified (refer to Table 
25). That is, *XX' indicates the com- 
ponent to be modified. 



RETURN : Control is returned from the PATCH 
routine to the instruction immediately fol- 
lowing the DC C'XX • instruction. 



Table 24. Data Set Disposition 
Field Bit Meanings 



JBits 0- 


— T _ _ 

-l|Not used 
. 1 






i 


|Bit 


2 


(TCLOSE 
_ i 


the 


DCB 


for 


SYSIN | 


|Bit 


3 


| TCLOSE 


the 


DCB 


for 


SYS PUNCH | 


|Bit 


4 


| TCLOSE 
. j 


the 


DCB 


for 


SYSLIN | 


|Bit 


5 


t — 
j TCLOSE 
-4. 


the 


DCB 


for 


SYSUT1 | 


|Bit 


6 


T 

j TCLOSE 


the 


DCB 


for 


SYSUT2 | 


|Bit 


7 


| TCLOSE 
. J. 


the 


DCB 


for 


SYSPRINT | 
J 



Print Control Operations 

The linkage to the interface module for 
a print control operation is : 



BAL 

DC 

DC 

where: 



15, FPRTCTRL 
B • xxxxxxxx ' 
AL3 (IOERR) 



• FPRTCTRL is the name of a oranch 
instruction in the communication area 
that branches to the print control 
operations routine (PRTCTRL) of the 
interface module. 



• FNEXT is the name of a branch instruc- 
tion in the communication area that 
branches to the end-of-phase routine 
(SNEXT) of the interface module. 

RETURN: Control is never returned to the 
caller; it is transferred to the next phase 
or interlude via the XCTL macro-instruction 
(refer to Table 25) . 



• 'xxxxxxx' is the carriage control char- 
acter. 

• AL3 (IOERR) is an ' address constant 
containing the address of the I/O error 
routine of the component requesting the 
print control operation. 



RETURNS : The PRTCTRL may return to the 
caller either normally or abnormally. 



Patch Requests 



The linkage to the interface module for 
a patch request is: 

LR WRKREG, BASEA 
BAL 15, FPATCH 
DC C'XX* 



Normal Return: The normal return is to the 
immediately following the 
instruction. 



instruction 
DC AL3( IOERR) 



Abnormal Return: The abnormal return is to 
the I/O error routine within the caller. 
The contents of general registers 14 and 
are the same as that described for an 
abnormal return for an I/O request. 
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LINKAGE TO THE PERFORMANCE MODULE 

For PRFRM compilations, the components 
of the compiler link to the performance 
module (IEJFAPAO) for: 

• Input/output requests. 

• End-of-phase requests. 

Input/Output Request Linkage 



The linkage to the performance module 
for an I/O request is the same as that 
described for the linkage to the interface 
module for an I/O request. However, the 
FIORTN field in the communication area is 
effectively replaced, by Phase 5, with a 
branch to the PIORTN routine in the perfor- 
mance module. All I/O requests for PRFRM 
compilations are automatically rerouted to 
the PIORTN routine. The PIORTN routine, in 
turn, links to the I/O routine (SIORTN) of 
the interface module when it is either 
ready to read or write, or to check the 
result of a previous read or write. 

RETURNS : The returns from the PIORTN rou- 
tine are the same as those described for 
the SIORTN routine. 



End-Of-Phase Request Linkage 



The linkage to the performance module 
for an end-of-phase request is the same as 
that described for the linkage to the 
interface module for an 
end- of -phase/interlude request. However, 
the FNEXT field in the communication area 
is effectively replaced by Phase 5, with a 
branch to the PNEXT routine in the perfor- 
mance module. All end-of-phase requests 
for PRFRM compilations are automatically 
rerouted to the PNEXT routine. 



RETURN: Control is never returned to the 
caller; it is transferred to the next phase 
via the XCTL macro- instruct ion. 



Note: Internally, the compiler components 
use symbolic names when transferring con- 
trol to a subsequent component. The sym- 
bolic names and the actual names of the 
components are illustrated in Table 25. 



Table 25. Symbolic and Actual Names of 
Compiler Components 

r t 1 

| Symbolic Name | Actual Name | 



IEJFAAAO 


a. 


2 


| Phase 1-Ir 


litial entry 


IEJFAABO 






| Phase 1-Subsequent entries 


IEJFAGAO 


a. 
i 


3 


| Interface 


module 


IEJFAPAO 


a. 
i 


3 


| Performance module 


IEJFAXAO 




3 


| Source symbol module 


IEJFCAAO 


3 




| Phase 5 




IEJFEAAO 






| Phase 7 




IEJFFAAO 






| Phase 8 




IEJFGAAO 






(Phase 10D 




IEJFJAAO 






| Phase 10E 




IEJFJGAO 






| Interlude 


10E 


IEJFLAAO 






| Phase 12 




IEJFNAAO 






| Phase 14 




IEJFNGAO 






| Interlude 


14 


IEJFPAA0 






| Phase 15 




IEJFPGAO 






| Interlude 


15 


IEJFRAAO 






| Phase 20 




IEJFVAAO 






| Phase 25 




IEJFVCAO 


1 
l 


<* 


| Object listing module 


IEJFXAAO 






| Phase 30 





1 Never receives control, via the XCTL 
macro- instruction, from another compiler 
component. 

transferred to (via XCTL macro- 
instruction) by calling program. 

3 Loaded (via LOAD macro- instruction) by 
Phase 1. 

^♦Loaded (via LOAD macro-instruction) by 
Phase 25. 
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APPENDIX D: DATA CONTROL BLOCK MANIPULATION 



The manipulation of the data control 
blocks for the data sets required by the 
compiler depends on whether a SPACE or a 
PRFRM compilation is being performed- For 
SPACE compilations, there is more data 
control block manipulation because of main 
storage limitations. (The main storage 
required to contain all the BSAM routines 
and the control blocks for I/O operations 
may not be available or may be restricted 
from the compiler by the value specified in 
the SIZE option. ) For PRFRM compilations , 
the availability of main storage is not a 
limitation. Therefore, less data control 
block manipulation is required. 



FOR PRFRM COMPILATIONS 



For PRFRM compilations, Phase 1 initial- 
ly opens the data control blocks for all 
the data sets required by the compiler. 
Because all the required data control 
blocks are opened initially, the compiler 
can bypass the execution of Interludes 10E, 
14, and 15. Bypassing the execution of the 
interludes reduces data control block 
manipulation and phase-to- phase transition 
time; therefore, compilation time is also 
reduced. 



For both SPACE and PRFRM batch compila- 
tions (i.e., more than one source module), 
the SYSPRINT, SYS LIN, and SYSPUNCH data 
sets are manipulated so that each data set 
contains the output for the entire compila- 
tion (i.e., for all the source modules). 
However, for a batch SPACE compilation, if 
the SYSOUT parameter is used on the DD 
statements associated with SYSPRINT, SYS- 
LIN, and/ or SYSPUNCH; new data sets are 
created for the output of each of the 
compiled source modules. 



FOR SPACE COMPILATIONS 



For a SPACE compilation, Phase 1 ini- 
tially opens only the data control blocks 
for the data sets used by Phases 5, 7, 8 
(if the ADJUST option is in effect), 10D, 
and 10E (SYSIN, SYSUTl, SYSUT2, SYSPRINT). 
For the remainder of the compilation, the 
data control blocks are opened by the 
interludes only when their corresponding 
data sets are to be used by a specific 
compiler component. Each interlude first 
closes all the data control blocks and then 
opens only those that are to be used. This 
process decreases the size of the resident 
BSAM routines and provides the compiler 
with the additional main storage necessary 
for compilation. 



Figure 24 (refer to Note 1) illustrates 
the manipulation of data control blocks for 
SPACE compilations. 



Figure 25 (refer to Note 1) illustrates 
the manipulation of data control blocks for 
PRFRM compilations. 



Note 1 ; In Figures 24 and 25, OPEN indi- 
cates that the data control block is opened 
during execution of a compiler component. 
CLOSE indicates that the data control block 
is closed during execution of a compiler 
component. TCLOSE indicates that the cor- 
responding data set is logically reposi- 
tioned to the beginning of the data set for 
subsequent reading or writing. IN, OUT, 
INOUT, and OUTIN indicate that the corres- 
ponding data set is used for initial or 
intermediate compiler input, for intermedi- 
ate or final compiler output, for input 
followed by output, and for output followed 
by input. READ indicates that the corres- 
ponding data set is read from during execu- 
tion of a compiler component. WRITE indi- 
cates that the corresponding data set is 
written onto during execution of a compiler 
component. FLUSH indicates that the con- 
tents of the buffer currently being used 
are written out (only for a PRFRM compila- 
tion with blocking) . 



Note 2; For SPACE compilations, READ, 
WRITE, and TCLOSE operations are controlled 
by the interface module. For PRFRM compi- 
lations, READ, WRITE, FLUSH, and TCLOSE 
operations are controlled by the perfor- 
mance module. (Figure 25 shows the logical 
DCB manipulation, rather than the actual 
DCB manipulation, since blocking on SYSIN, 
SYSLIN, SYSPUNCH, SYSPRINT, and SYSUT2 (for 
ADJUST runs) , and chaining on SYSUTl and 
SYSUT2 determine when these operations are 
actually performed. 
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Figure 24. Data Control Block Manipulation for SPACE Compilations 
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Figure 25. Data Control Block Manipulation for PRFRM Compilations 
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APPENDIX E: SOURCE STATEMENT SCAN 



Phase 10D and Phase 10E convert each 
FORTRAN source statement into a form 
(intermediate text) usable to subsequent 
phases of the compiler. Intermediate text 
is developed by scanning the source state- 
ments from left-to-right and by construct- 
ing four-byte intermediate text entries for 
the source text contained in the state- 
ments. (Six- byte entries are constructed 
for EQUIVALENCE statements.) 



Phase 10D scans the declarative state- 
ments in the source module, and creates 
intermediate text for those statements. 
When Phase 10D encounters either the first 
statement function or the first executable 
statement, control is passed to Phase 10E 
via the interface module. Phase 10E con- 
tinues the scan of the source module and 
creates intermediate text for statement 
functions and executable statements. 

As source statements are scanned, 
entries are made to the dictionary and 
overflow table. The information in the 
dictionary and overflow table supplements 
the intermediate text in the generation of 
machine-language instructions by subsequent 
phases of the compiler. This information 
is associated with the intermediate text 
entries by means of pointers that reside in 
the text entries. 

Each source statement of the source 
module consists of one or more card images. 
To scan source statements, each card image 
of the source module is first read into one 
of two I/O buffers in the interface module 
(IEJFAGAO). The double- buf f er scheme 
allows for overlapping the scanning of a 
card image in one buffer with the reading 
of the next card image of the source module 
into the other buffer. If the SOURCE and 
NOADJUST options are in effect, the I/O 
buffers are used to print a listing of the 
source module. 

In general, the processing of a source 
statement is divided into three operations: 

• Preliminary scan of the card image (s) 
for the statement. 



• Classification scan of the 
image for the statement. 



first card 



PRELIMINARY SCAN 



The preliminary scan first determines 
the address of the end of the source text 
in the card image to be processed. This 
address is obtained by examining the card 
image from right-to-left in groups of four 
bytes. The address of the last blank group 
encountered is used as the ending address 
of the card image. This address is used in 
the reserved word or arithmetic scan of the 
card image and indicates the point at which 
the scan of the card image and the creation 
of intermediate text for the card image is 
to terminate. In the case of the last card 
image for a statement, the ending address 
indicates the end of the statement. 

The preliminary scan then determines the 
type of the card image to be scanned. A 
card image may correspond to the start of a 
FORTRAN statement, the continuation of a 
FORTRAN statement, or a user's comment. 

If the card image corresponds to the 
start of a FORTRAN statement, a unique 
internal statement number is assigned to 
the statement. This number is placed in 
front of the card image in the buffer 
containing that card image. Control is 
then passed to the classification scan. 

If the card image corresponds to a 
continuation of a FORTRAN statement, a new 
internal statement number is not assigned. 
Control is immediately passed to the clas- 
sification scan. 

If the card image corresponds to a 
user's comment, no further processing is 
required. The next card image of the 
source module is read into the buffer that 
contained the comments card image. The 
address of the other buffer (previously 
filled) is obtained from the communication 
area, and scanning starts for the card 
image in that buffer. 

In each case, if the SOURCE and NOADJUST 
options are in effect the buffer containing 
the card image is first written onto the 
SYSPRINT data set before any further proc- 
essing. 



Reserved word or arithmetic scan of the 
card image(s) for the statement, which 
scans the source text of the statement. 
(The reserved word or arithmetic scan 
also creates intermediate text. ) 



CLASSIFICATION SCAN 



The classification scan determines the 
type (arithmetic or reserved word) of the 
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FORTRAN statement to be processed. The 
first action taken by the classification 
scan is to determine if a statement number 
defines the statement under consideration. 
If a statement number is associated with 
the statement, an overflow table entry for 
that statement number is created. 

The next item of the source statement is 
then obtained. If the item is a symbol, 
control is passed to a routine that scans 
arithmetic statements. If the item is a 
reserved word (e.g., READ), control is 
passed to the appropriate reserved word 
routine. The arithmetic or reserved word 
routine controls the scanning of the 
remainder of the statement, and creates 
intermediate text for the statement. 

If the item is neither a symbol nor a 
reserved word, the source statement in 
question is invalid. Processing of that 
statement is terminated, and processing of 
the next statement of the source module 
begins . 



RESERVED WORD OR ARITHMETIC SCAN 



The main function of the reserved word 
or arithmetic scan is to scan the card 
image (s) for each statement of the source 
module. During this scan, dictionary and 
overflow table entries are constructed, and 
intermediate text entries are created. In 
addition, each statement is examined for 
correct use of the FORTRAN IV (E) language. 

The reserved word or arithmetic scan is 
performed by either a reserved word routine 
or the arithmetic routine. A reserved word 
routine exists for each of the reserved 
word source statements. Certain reserved 
word routines, namely those that process 
statements that may contain arithmetic 
expressions (e.g., IF and CALL statements) 
and those that process statements that 
contain I/O lists (e.g., READ and WRITE 
statements) pass control to the arithmetic 
routine to complete the scanning of the 
associated reserved word statements. 



The intermediate text for each card 
image is developed by constructing inter- 
mediate text entries for operator-operand 
pairs as they are scanned by a reserved 
word routine or the arithmetic routine. In 
this context, operator refers to commas, 
parentheses, etc., as well as to arithmetic 
operations (e.g., + and -) . Operand refers 
to variables, constants, statement numbers, 
data set reference numbers, etc., that are 
operated on. 



The procedure of: (1) scanning operators 
and operands, (2) constructing dictionary 
or overflow table entries when necessary 
for the operands, and (3) developing inter- 
mediate text entries for the operator- 
operand pairs is repeated until the end of 
the card image is recognized by the 
reserved word or arithmetic scan. 

When the address indicating the end of 
the card image is recognized by the res- 
erved word or arithmetic scan, the next 
card image of the source module is read 
into the buffer that contained the card 
image just processed. The address of the 
other buffer (previously filled) is 
obtained from the communication area, and 
processing starts for the card image in 
that buffer. 

When an entire source statement has been 
scanned, a special intermediate text entry 
indicating the end of the intermediate text 
representation for a given statement is 
generated and then written onto an inter- 
mediate storage data set at the end of the 
intermediate text representation for the 
statement. This special text entry con- 
tains the internal statement number 
assigned to the statement by the prelimi- 
nary scan section. 

During the reserved word or arithmetic 
scan, each card image is examined for 
proper use of the FORTRAN IV (E) language. 
The format of the card image is checked to 
see if the statement associated with the 
card image has been coded properly by the 
source programmer. 



When the appropriate reserved word rou- 
tine or the arithmetic routine receives 
control, a left-to-right scan of the cur- 
rent card image is then initiated. The 
first operand of the card image is 
obtained, and a check is made to determine 
if a dictionary or overflow table entry has 
previously been created for the operand. 
If an entry has not been created, a dic- 
tionary or overflow table entry (depending 
on the operand) is created and entered in 
the appropriate resident table. Scanning 
is resumed and the first operator of the 
card image is obtained. 



If a serious error is encountered, scan- 
ning of the statement associated with the 
card image is terminated. An intermediate 
text word indicating the end of the inter- 
mediate text representation for the state- 
ment is generated and then written onto an 
intermediate storage data set. This text 
word also indicates that an error was 
encountered in the processing of the state- 
ment. An intermediate text word, rep- 
resenting the error, which contains a num- 
ber corresponding to the specific error 
detected, is generated and then written 
onto the intermediate storage data set at 
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the end of the intermediate text represen- 
tation for the statement in which the error 
was detected. 



If an error is encountered that is not 
serious enough to terminate the scan of a 
statement, an intermediate text word rep- 
resenting a warning is generated. This 
word is saved and scanning is resumed. 
When the scan of the statement is terminat- 
ed (either when the end of the statement is 
recognized or when a serious error is 
encountered) , the warning text word is 
written onto the intermediate storage data 
set immediately following the text word 
that indicates the end of the intermediate 



text representation for the statement and 
any intermediate text words generated for 
serious errors. (A maximum of four warning 
text words per statement may be saved and 
then written onto the intermediate storage 
data set. If more than four warning condi- 
tions are encountered, an intermediate text 
word representing an error is generated and 
scanning of the statement is terminated. ) 



The source statement scan for the fol- 
lowing READ statement is illustrated in 
Chart DO. 



READ (5,10) A,B(1), (C(I) , 1=1, 10) ,D 
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Chart DO. READ Statement Scan Logic 



• DO » 

* Al* 



* SET UP * 

* READ BCD *- 

* ADJ CODE » 

* » 
*#»»#*»*•#####•** 



-#_»_#_#- 



##••##« 



» ENTER 

* VARIABLE IN 

* DICTIONARY 

#####♦#♦*»*####« 



GET DATA SET * 

REFERENCE * 

NUMBER * 

»•••••••*••*•••• 



#—#—#—#—#—#—#—#—# 
>» PROCESS *- 

* SUBSCRIPTED * 

• VARIABLE • 

###*»###**»»##»♦# 



#—#-#-#_#-#-#_#_# 
>* ENTER * 

* INTO * 

* TEXT « 

##•############## 



L 



* ENTER * 
» DSRN IN • 

* DICTIONARY » 

*•*«*•«•#*«#*#*** 



END OF 

STATEMENT 

PROCESSING 

»##########« 



*#»#*D1 *######### 

* • 
•CHANGE ADJ CODE* R PAREN »-*-#-#-#- 

* TO UNFORMATTED*< 

* READ * 

* * 
##*##*##**###»*** 



-* GET OPERATOR 



-#—»—«—#- 



»*#*#•*##*»»##•*# 



####05********* 

* START 

» ON NEXT 

• STATEMENT 

#*####*##•##### 



* ENTER ADJ * 

* CODE INTO * 

* TEXT * 

#•**•*«»«***»#*#* 



* ENTER ADJ 
» CODE INTO 

* TEXT 

••***••#••#•••« 



* ENTER 

* PARAMETER IN 
» DICTIONARY 

••#•#•#••••••»« 



* GET FORMAT * 

* STATEMENT * 

* NUMBER « 

**•••••••#*••••#« 



*—*—»—»—#—*-*- 

* ENTER 

* PARAMETER 

* INTO TEXT 
*»*»»*»##♦**** 



GENERATE * 
APPROPRIATE * 
ERROR TEXT * 

»#•###•##«###•# 



* ENTER 

* STMT NUMBER 
♦IN OVERFL TBL 

##****### »*•«#»* 



•«**#»*#*##*•###* 



#*** # 
» *OTHER« 
» F5 *< * 



**#*#K1 ********** 

* * 

* SET UP * 

* ADJ CODE *< 

* FOR OPERATOR * 

* • 
######♦#######♦## 



* ENTER PTR TO * 

* STMT NUMBER • 

* INTO TEXT * 
**•*••##••##*•#•• 

* » < 

* K2 *-> 

* # 
**## 

ARITH10 V 

*»»»»K2»********* 

* GETWD * 
ZERO*-*-*-*-*-*-*-*-* 

* GET * 

* NEXT * 

* WORD * 
**«####*####**##* 

I NON-ZERO 



>* ENTER 
» OPERATOR 
* INTO TEXT 

##«*•*#*•***## 



>* ENTER IMMED * 
» PARAMETER « 
* OF ONE - * 

#»»#»##»######»»« 



»••* 
# 
A3 * 



• •** 

* FS « 

* « 

**»* 
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APPENDIX F: INTERMEDIATE TEXT 



Intermediate text is an internal rep- 
resentation of the source statements from 
which the machine- language instructions are 
produced. The conversion from intermediate 
text to machine-language instructions 
requires information about variables, con- 
stants, arrays, statement numbers, in-line 
functions, and subscripts. This informa- 
tion, derived from the source statements, 
is contained in the dictionary and overflow 
table, and is referenced by the intermedi- 
ate text. The dictionary and overflow 
table supplement the intermediate text in 
the generation of machine instructions by 
the various phases of the compiler. 



Phase 20 modifies the intermediate text 
entries that represent subscript expres- 
sions. Registers are assigned to subscript 
expressions (once they have been initially 
computed) and are inserted in the text 
entries for those expressions. 

Phase 25 uses the intermediate text in 
conjunction with the overflow table to 
generate the object module instructions. 

Phase 30 uses the intermediate text to 
generate any error and warning messages and 
to process the END statement. 



Phases 10D and 10E create intermediate 
text for use as input to subsequent phases 
of the compiler. Intermediate text is 
created by Phase 10D for the following 
declarative statements : 



COMMON and EQUIVALENCE 

DEFINE FILE 

FORMAT 

SUBROUTINE or FUNCTION 

Specification statements 



Phase 10E creates intermediate text for 
all statement functions and executable 
statements in the source module and for 
FORMAT statements interspersed within the 
executable statements. 

Phase 12 uses COMMON and EQUIVALENCE 
text during relative address assignment. 



AN ENTRY IN INTERMEDIATE TEXT 



The intermediate text is constructed by 
Phases 10D and 10E for some declarative 
statements, all statement functions, and 
all executable statements. Each statement 
is represented in the intermediate text by 
one or more intermediate text words. (An 
intermediate text word is four bytes long.) 
This word normally contains three fields 
(as illustrated in Figure 26). 

r t t 1 

| adjective code | mode/type | pointer | 

| field | field | field | 
|. + + ., 

| 1 byte | 1 byte | 2 bytes | 
l j. x : j 

Figure 26. Intermediate Text Word Format 



Phase 14 converts the FORMAT intermedi- 
ate text to a form acceptable to IHCFCOME. 
It also inserts the addresses assigned by 
Phase 12 to variables, constants, etc., 
into the intermediate text. In addition, 
Phase 14 modifies the intermediate text for 
READ/WRITE statements. Phase 14 also 
deletes any COMMON and EQUIVALENCE text 
from the intermediate text since that text 
is no longer needed. 

Phase 15 reorders the sequence of inter- 
mediate text entries in statements that can 
contain arithmetic expressions, and modi- 
fies these entries to a format that closely 
resembles machine- language instructions. 
The intermediate text for DEFINE FILE 
statements is also reordered by Phase 15. 
Machine operation codes and registers (when 
required) are inserted in the intermediate 
text. Argument lists for external and 
function references are created by modify- 
ing the intermediate text for those state- 
ments . 



Adjective Code Field 



The adjective code field in the initial 
intermediate text word indicates the type 
of statement for which the intermediate 
text entries are constructed, i.e.: 

• Reserved word, e.g., DO, CALL, GO TO. 

• Statement function (SF) . 

• Arithmetic. 

The adjective codes in the subsequent 
intermediate text words for a statement 
indicate: 

• Delimiters, i.e., +-*/** () , 

• The end of a statement (end mark) 

• An error 

Each adjective code is composed of two 
hexadecimal digits. The various adjective 
codes possible (and their use) are indicat- 
ed in Figure 27. 
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O 



\L 
H\o 
i\w 

g\ 

h\| 

, + ^ + — ^ + + + — 



Y~ 






Y i 

5 



— ^ 

6 

F \ 

7 

I 1 

8 



I + 

E 



+ 



| + + + 

LCR 






FUNC- 
TION 



END 



UNARY 
MINUS* 






+ 



END 
DO 



CALL 



SAOP 



IN- 10 
LINE 
FUNC 
f 






CON- 
TINUE 



ARITH- 
METIC 
IF 






|BC 10 | 



INTEGER 



UNCONDI- 
TIONAL 
GO TO 



SIZE OF 
ARRAY 






DOUBLE 



ARITH 



+ H 



T T" 



END 
MARK 



REAL 



BACK- 
SPACE 






ARGU- 
MENT 



|N" 



ILLEGAL 
+ 



j BLANK 
I 

-Y 



HO 

|A 
ID 



REWIND 



| END 
I FILE 



COMPUT- 
ED 
GO TO 



BEGIN 

I/O 

LIST 



| END 

jl/O 

| LIST 

■+ 






FUNC( 






\ +- 



| + + 1 + + - 



|SRDA 10 

| COMMON | EQUIVA- | EXTER- | | DIMEN- | DEFINE | | SUBROU- 
LENCE |NAL j |SION |FILE j |TINE 



WRITE 
BINARY 



+ 



READ 
BINARY 



+ + + ^ + . 



WRITE 
BCD 



PAUSE 



UNARY 
PLUS 10 



READ 
BCD 



ARITH 
IF 






I INTEGER 



DO | STMNT 
NO. 
DEF. 

IMP | ERROR 
DO | MESS- 
AGE 



4 

1 



j 



io 
APOSTROPHE 



Y 

DOUBLE PRECISION 



.j 



H 



h 



REAL 



WARNING 
MESS- 
AGE 



"Subject to change in later phases. 



Figure 27. Intermediate Text Adjective Codes 



Mode/Type Field 



The mode/type field indicates the mode 
and the type of a symbol; e.g., a real 
function for a function name, or dummy 
variable for the variable name. These 
mode/type codes are the same as those used 
in the dictionary entries (refer to Appen- 
dix HK 



the internal statement numbers appearing in 
the intermediate text. Errors in the 
source module may cause the same statement 
number to be assigned more than once. If 
the user has requested a source listing, 
the internal statement number assigned to 
each statement appears next to that state- 
ment in the listing. 



In the word with an end mark adjective 
code, another indicator may appear in the 
mode/type field. Normally, this field con- 
tains zeros; however, if any errors or 
warnings are detected in a statement, this 
field contains a hexadecimal 01. 



AN EXAMPLE OF INTERMEDIATE TEXT 



Figure 28 illustrates the intermediate 
text created by Phase 10E for the following 
IF statement. 



If errors or warnings are detected, the 
error/warning message number appears in the 
mode/type field of the word inserted in the 
intermediate text to represent that 
error/warning. Errors and warnings are 
detected by Phases 10D, 10E, 12, 14, 15, 
and 20. 



Pointer Field 



The pointer field consists of the last 
two bytes of the intermediate text word. 
It normally contains a relative pointer to 
the dictionary or overflow table entry for 
the symbol with which the adjective code is 
associated, e.g., the term +A has a + 
adjective code and an associated pointer 
field that contains a relative pointer to 
the dictionary entry for A. The pointer 
field may also be used to contain either 
the increment of a DO or implied DO vari- 
able, or the internal statement number in 
the word containing the end mark or the 
error/warning adjective code. 



The internal statement number is 
assigned during Phases 10D and 10E to each 
FORTRAN source statement. This number dif- 
fers from the user-assigned statement num- 
ber. It is assigned whether or not inter- 
mediate text is to be created for that 
statement; therefore, there may be gaps in 



IF ( + 19 - MART) 11, 7, 61 



r 


~T 




T" 




| adjective code 




mode/type 




pointer 


| field 




field 




field 


| (1 byte) 


I 


(1 byte) 


1 


(2 bytes) 




1 




1 




| statement 




statement 




p(3) 


| number 


l 


number 


| 






1 




! 




| arithmetic IF 


1 


00 


1 


0000 




1 




1 




| ( 


I 


00 


1 


0000 




1 




1 




| unary + 


l 


integer 
constant 


1 


p(19) 




1 




1 






l 


integer 
variable 


I 


p (MART) 




1 




1 




| ) 


l 


statement 
number 


1 


p(ll) 




1 




1 




1 i 


l 


statement 
number 


1 


p(7) 




1 




1 




1 t 


-+- 


statement 
number 


-+- 


p(61) 


| end mark 




00 




internal 

statement 

number 













Figure 28. Example of Intermediate Text 
for an IF Statement 
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UNIQUE FORMS OF INTERMEDIATE TEXT 



Subscripted Variable 



When intermediate text is created, there 
are four unique forms: the text for FORMAT 
statements; subscripted variables; COMMON 
statements; EQUIVALENCE statements; and 
READ, FIND, and WRITE statements. 



When a subscripted variable is encoun- 
tered in a source statement, an entry for 
the variable is made. That entry is fol- 
lowed by two additional intermediate text 
words to define the subscripted expression. 
Figure 30 illustrates the format of the 
first word. 



FORMAT Statements 



For FORMAT statements, the adjective 
code field of the first intermediate text 
word of the statement indicates a FORMAT 
statement; the remaining two fields contain 
three bytes of the FORMAT statement card 
image. The remainder of the card image of 
the FORMAT statement appears in the follow- 
ing intermediate text words. Figure 29 
illustrates the intermediate text created 
for the following FORMAT statement. 



r t t 1 

| adjective code | mode/type | pointer | 
| field | field | field | 
| (1 byte) J (1 byte) | (2 bytes) | 
,. + + ^ 

I SAOP J 00 J offset J 

,. x x ., 

| SAOP represents the subscript arithmetic | 
j operator, and the offset represents a| 
I part of the array displacement. (Refer j 
| to Appendix G for a discussion of array j 
j displacement. ) j 

l J 

Figure 30. Subscripted Variable Intermedi- 
ate Text - (First Word) 



12 FORMAT (F20.5,I6) 



Figure 31 illustrates the format of the 
second word. 



t t 

adjective | mode/ type | pointer 
code field | field j field 
(1 byte) | (1 byte) j (2 bytes) 
+ + 

statement | statement | 
number j number j p(12) 

FORMAT j ( j F j 2 
X X X 

I • | 5 | , 
X X X 

1 j 6 j ) [blank 

X X -L_ 



blanks represent the remaining card 
columns to column 72 

(Each card column represents 1 byte. A 
hexadecimal *DF' follows the last card 
column. ) 





1 




1 


internal 


end mark 


1 
1 

X 


00 


1 

1 
x_ 


statement 
number 



Figure 29. FORMAT Statement Intermediate 

Text 



r t t 

adjective code| mode/type | pointer 

field | field | field 
(1 byte) | (1 byte) | (2 bytes) 

j. x x 1 



p( subscript 
information) 



| p (dimension 
j information) 
x. 



,. x ., 

The first field contains a relative poin- 
ter to the subscript information in the 
overflow table if the subscripted expres- 
sion contains variables. If the sub- 
scripted expression does not contain 
variables, this field contains zeros. 



The second field contains a relative 
pointer to the dimension information in 
the overflow table for the array that 
contains the subscripted expression. For 
example, if A (I, J) is an element in 
array A, the field contains the pointer 
to the dimension information for array A. 
l J 

Figure 31. Subscripted Variable Intermedi- 
ate Text - (Second Word) 
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Figure 32 illustrates the intermediate 
text created for the following statement, 
which involves two subscripted variables. 



APPLE = A(P0T,3) + B(2,l) 



adjective 
code field 
(1 byte) 



arithmetic 
statement 



mode/type 
field 
(1 byte) 



mode/type 
Of APPLE 



mode/type 
of A 



SAOP 



00 



p( subscript 
information) 



+ 
SAOP 



mode/ type 
of B 

00 



00 



end mark 



00 



00 



pointer 

field 

(2 bytes) 



p (APPLE) 



p(A) 



offset 



p (dimension 
information) 



p(B) 
offset 






+- 



p (dimension 
information) 



internal 

statement 

number 



COMMON Statements 



COMMON intermediate text is constructed 
by Phase 10D as a series of four-byte 
entries (one for each variable or array 
name that appears in a COMMON statement) . 
Phase 12 serially references these entries 
and assigns addresses to them in the COMMON 
area. (The assignment of addresses is 
discussed in detail in the Phase 12 des- 
cription. ) 

Figure 33 illustrates the intermediate 
text created for a COMMON statement. 



AN EXAMPLE OF COMMON INTERMEDIATE TEXT; 
Figure 34 illustrates the intermediate text 
created for the following COMMON statement. 

COMMON (A,R,ARNONN) 



|98 


T ~ " 

J not used 


-T- 

1 

I 


not 


used | 


|p(A) 


T 

1 
— J. - 


1 


1 

1 

1 


not 


used | 


|p(R) 
|p(ARNONN) 


T 

1 

1 


1 

6 


1 
1 

1 
1 


not 
not 


used | 
used j 


| 00000001 | 


|2 bytes 


T 


byte 


1 

1 
1 - 


1 byte | 
j 



Figure 32. Example of Subscripted Variable 
Intermediate Text 



Figure 34 



Example of COMMON Intermediate 
Text 



98 



not used 



not used 
not used 



pointer to the dictionary entry for the 
first variable or array name in statement 



2 length of the 
first variable 
or array name 
in statement 



pointer to the dictionary entry for the 
last variable or array name in statement 



length of the 
last variable 
or array name 
in statement 



not used 



00000001 



2 bytes 



1 byte 



1 byte 



^-Indicates COMMON intermediate text. 

2 The length is used to determine the dictionary chain in which the variable or array 

name is entered. 
3 Indicates the end of the intermediate text for the COMMON statement. 

Figure 33. COMMON Intermediate Text 



Appendix F: Intermediate Text 
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EQUIVALENCE Intermediate Text 



EQUIVALENCE intermediate text is con- 
structed by Phase 10D as a series of 
six-byte entries (one for each variable or 
array name that appears in an EQUIVALENCE 
statement) . Phase 12 serially references 



these entries and assigns addresses to 
them. (The assignment of addresses is 
discussed in detail in the Phase 12 des- 
cription. ) 



Figure 35 illustrates the intermediate 
text created for an EQUIVALENCE statement. 



99 



not used 



pointer to dictionary 
entry for first vari- 
able or array name in 
first EQUIVALENCE 
group in statement 



size of first variable 
or array in first 
EQUIVALENCE group in 
statement 



2 offset of first vari- 
able or array in first 
EQUIVALENCE group in 
statement 



pointer to dictionary 
entry for last vari- 
able or array name in 
first EQUIVALENCE 
group in statement 



size of last variable 
or array in first 
EQUIVALENCE group in 
statement 



offset of last vari- 
able or array in first 
EQUIVALENCE group in 
statement 



000F 



pointer to dictionary 
entry for first vari- 
able or array name in 
last EQUIVALENCE 
group in statement 



size of first variable 
or array in last 
EQUIVALENCE group in 
statement 



offset of first vari- 
able or array in last 
EQUIVALENCE group in 
statement 



pointer to dictionary 
entry for last vari- 
able or array name in 
last EQUIVALENCE 
group in statement 



size of last variable 
or array in last 
EQUIVALENCE group in 
statement 



offset of last vari- 
able or array in last 
EQUIVALENCE group in 
statement 



000F 



00000001 



2 bytes 



2 bytes 



2 bytes 



1 Indicates EQUIVALENCE intermediate text. 

a Contains 0000 if the variable or array is not subscripted. 

3 Indicates the end of the intermediate text for an EQUIVALENCE group. 

^Indicates the end of the intermediate text for the EQUIVALENCE statement. It must 

reside on a full-word boundary. If necessary, this entry is preceded by two bytes of 

zeros in order to adjust it to a full-word boundary. 

L 

Figure 35. EQUIVALENCE Intermediate Text 



110 



Note: Phase 10D generates a special eight- 
byte intermediate text entry following the 
last EQUIVALENCE statement. This special 
entry indicates to Phase 12 that it can 
ignore the remaining intermediate text on 
SYSUT1 because it has processed all of the 
COMMON and EQUIVALENCE intermediate text. 
The special entry has the following format: 



r t t 

j 99FF0000 j 00000001 j 

Y + 1 

j 2 bytes j 2 bytes j 
l x J 



AN EXAMPLE OF EQUIVALENCE INTERMEDIATE 
TEXT: Consider the following EQUIVALENCE 
statement: 

EQUIVALENCE ( GRW, KEL) , (RBJ (1,9), AMV (2,4)) 

There are two EQUIVALENCE groups in the 
statement: 

• GRW, KEL 

• RBJ(l,9) r AMV<2,4) 



Assume that: 

• GRW is a real variable. 

• KEL is an integer variable. 

• RBJ is a real array dimensioned as 
(9,9). 

• AMV is a real array dimensioned as 
(9,4). 



READ/WRITE and FIND Statements 



Phase 10E generates intermediate text 
for: (1) both sequential and direct access 
READ/WRITE statements, and (2) direct 
access FIND statements. (Phase 10E inter- 
prets the FIND statement as a direct access 
READ statement without format and without 
I/O list.) 



The intermediate text generated for both 
sequential and direct access READ/WRITE 
statements is essentially the same. The 
main difference is that additional inter- 
mediate text must be generated for direct 
access statements for the integer expres- 
sion (r) that represents the relative posi- 
tion within the data set of the record to 
be read or written. 



If the integer expression contains any- 
thing other than a constant, or a nonsub- 
scripted integer variable, Phase 10E gener- 
ates special intermediate text to evaluate 
that expression. This special text is 
treated as an arithmetic expression. Phase 
10E also sets a switch (FDATEMP) in the 
communication area that indicates to Phase 
15 that an integer work area must be 
allocated. 



Figure 37 illustrates the intermediate 
text generated for a general I/O statement 
(that is, a sequential access READ or WRITE 
statement; or a direct access READ, WRITE, 
or FIND statement) . 



Figure 36 illustrates the intermediate 
text created for the above EQUIVALENCE 
statement. 



EXAMPLES OF INTERMEDIATE TEXT CREATED FOR 
SPECIFIC I/O STATEMENTS: The following 
figures illustrate the intermediate text 
generated by Phase 10E for specific I/O 
statements. 



H- 



99 



p(GRW) 



p(KEL) 



000F 



- T ., 

| not used | 



p(RBJ) | 81 | 72 
p(AMV) | 36 | 28 
000F | 00000001 



2 bytes j 2 bytes j 2 bytes 



Figure 36. Example of 

Intermediate Text 



EQUIVALENCE 



Figure 38 illustrates the intermediate 
text generated for the following sequential 
access READ statement. 

READ (1,10) (A(N),N=1,10), B 



Figure 39 illustrates the intermediate 
text generated for the following direct 
access WRITE statement. 

WRITE (5'I(J),10) (A(N) ,N=l f 10) ,B 



Figure 40 illustrates the intermediate 
text generated for the following direct 
access FIND statement. 

FIND (3' 5) 
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integer variable 
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p(u) 



integer variable 
| or constant 
,. 

| integer work area 



p(r) 
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x 

| statement 
j number 
_ x 








1 

1 

L _ 


p(f) 6 
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| 00 
_ x _ 








1 

1 

_ X 


0000 




intermediate text for 


I/O 


list 


if 


any 


7 


end mark 


— — - — T ~ 
1 

| 00 
_ _ A- 








" T ~ 
1 

1 

. X - 


internal 
statement number 



^This intermediate text is not created for: (1) sequential access I/O statements, or 
(2) direct access I/O statements if r (the integer expression indicating the relative 
position within a data set of the record to be read or written) is a constant or a 
nonsubscripted integer variable. 
2 IOCODE = A9, for non- formatted write 
= AA, for non-formatted read 
for formatted write 
for formatted read 
for sequential access READ/WRITE 
for direct access READ/WRITE 
for direct access FIND 
*»u is an integer constant or integer variable that represents a unit number. For 

direct access statements, u must be followed by an apostrophe ('). 
5 This intermediate text is not created for sequential access I/O statements. 
6 f is optional and, if given, is the statement number of the FORMAT statement 

describing the format of the data to be read or written. 
7 I/0 list is optional and, if given, is a series of variable or array names, separated 
by commas. The names represent the storage locations to be read into or written from. 

L 

Figure 37. Intermediate Text Created for General I/O Statement 



= AB, 
= AC, 
3 DACODE = 00, 
= 80, 
= CO, 
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adjective code field 
(1 byte) 



mode/ type field 
(1 byte) 



pointer field 
(2 bytes) 



formatted read 



sequential 
access I/O 



0000 



integer variable 



p(I) 



h- 



statement number 



p(10) 



00 



0000 



real subscripted 
variable 



p(A) 



SAOP 



00 



offset 



p (subscript information) 



p (dimension 
information) 



integer variable 



p(N) 



immediate DO 
parameter 



immediate DO 
parameter 



10 



immediate DO 
parameter 



00 



0000 



real variable 



p(B) 



end mark 



00 



internal statement 
number 



,. x 

| x If the third DO parameter is missing, Phase 10E assumes a value of 1. 

L 

Figure 38. Intermediate Text Created for READ (1,10) (A(N) , N=l,10) , B 
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adjective code field 
(1 byte) 



mode/type field 
(1 byte) 



pointer field 
(2 bytes) 



arithmetic 



integer work area 



0000 



subscripted 
integer variable 



p(I) 



SAOP 



00 



offset 



p (subscript information) 



j p( dimension information) 



end mark 



00 



0000 



formatted read 



direct access I/O 



0000 



unit 



p(5) 



integer work area 



0000 



statement number 



p(10) 



00 



0000 



real subscripted 
variable 



p(A) 



SAOP 



00 



offset 



p( subscript information) 



j p( dimension information) 



4- 



integer variable 



p(N) 



j immediate DO parameter 



j immediate DO parameter j 



10 



j immediate DO parameter j 



00 



0000 



real variable 



p(B) 



end mark | 00 | 

x. j 

Figure 39. Intermediate Text Created for WRITE (5'I(J), 10) (A(N) ,N=l f 10) , B 



internal statement number 



adjective code field 
(1 byte) 



mode/type field 
(1 byte) 



pointer field 
(2 bytes) 



non-formatted 
read 



direct access 
I/O for FIND 



0000 
p(3) 



unit 



constant 



p(5) 
0000 



00 



end mark 



00 



internal 
statement number 



Figure 40. Intermediate Text Created for FIND (3* 5) 
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MODIFYING INTERMEDIATE TEXT 



• Replacement of dictionary pointers 



The intermediate text is created by 
Phases 10D and 10E, and is modified by 
Phases 14, 15, and 20. This modification 
prepares the intermediate text for use by 
Phase 25 in the generation of machine- 
language instructions. The modifications 
made to the intermediate text are 
discussed, phase by phase, in the following 
pages. 



Phase 14 



During Phase 14 processing, the inter- 
mediate text is modified in the following 
ways : 



• Modification of I/O statement inter- 
mediate text. 

• Modification of computed GO TO inter- 
mediate text. 



• Modification of RETURN 
text. 



intermediate 



REPLACEMENT OF DICTIONARY POINTERS: Dic- 
tionary pointers in the intermediate text 
are replaced by information essential for 
the processing to be performed by subse- 
quent phases of the compiler. 

Figure 41 illustrates this modification 
to intermediate text entries. 



Input to Phase 14 



Output from Phase 14 



For: 



the dictionary pointer is replaced by: 



variables, constants, arrays, and external 
functions. 



r t t 1 

| adjective | mode/type j | 

| COde | Of ACCESS | p (ACCESS) | 
j. x + 1 

j 1 byte j 1 byte J 2 bytes | 
l x X J 



the relative address assigned by 
Phase 12. 



r t t 

| adjective | mode/type | 

| code j of ACCESS j a (ACCESS) 

|. + + 

| 1 byte | 1 byte | 2 bytes 
l x x 



data set reference numbers, 



r t t 1 

j ( | mode/type j p(3) j 

| 1 byte | 1 byte | 2 bytes | 
l x x J 



the data set reference number. 



( 



— T T n 

| mode/type | 3 | 
j. x x ., 

| 1 byte | 1 byte | 2 bytes j 
l x x J 



statement functions, 

definition 

r t t n 

|SF defini- |real state- | | 

jtion adjec-jment func- | p(SF) j 
jtive code |tion j j 

| 1 byte | 1 byte | 2 bytes | 
l x x J 

use 

r t t 1 

| SF use | real state- | | 

j adjective |ment func- j p(SF) | 
I code |tion | j 

|. x x i 

| 1 byte j 1 byte j 2 bytes j 
L X X J 



the SF number assigned by Phase 14. 



r t t i 

| SF defini- | real state- | the rela- | 
jtion adjec-|ment func- jtive SF | 
j tive code | tion j number | 

j 1 byte | 1 byte | 2 bytes | 



l 



r t t 

| SF use | real state-) the rela- 
| adjective jment func- jtive SF 
| code jtion j number 

| 1 byte j 1 byte | 2 bytes 
l x x 



Figure 41. Replacement of Dictionary Pointers by Phase 14 
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MODIFICATION OF I/O STATEMENT INTERMEDIATE 
TEXT; An I/O statement is modified in two 
ways. A begin I/O intermediate text word 
is inserted in the intermediate text for 
each element of an I/O list. Implied DOs 
are detected, and implied DO and end DO 
intermediate text words are entered in the 
text. An end I/O is placed at the end of 
the I/O list. 

These modifications are illustrated in 
Figures 42 and 43. The intermediate text 
in these figures is developed from the 
following sequential access non- formatted 
WRITE statement: 

WRITE (N) ((A(I r J) ,J=1, 10) ,1=1,15) 



r t 
| ad j ective | mode/type 
jcode field | field 
| (1 byte) | (1 byte) 

L J_ 


_ T 

| pointer field 
| (2 bytes) 

4- - 


l 


jnon 
jted 


format 
write 


- j sequential 
| access I/C 


T 

|0000 

x 




| ( 




T T 

|integer var. |p(N) 
_x_ j. 




|) 




| 00 

x 


|0000 
X 




| ( 




|00 

J. _ 


|0000 
4. - 




| ( 




T 

| real sub- 
script var 
_x_ 


T 

. |p(A) 

_ J. _ _ 




|SA0P 


| 00 

X 


T — 

| offset 
4. 




|p(s 


ubscript) 


T 

|p (dimension) 

X 




1 1 




T T 

| integer var.|p(J) 

-4. _ _ _ X 




| = 




T 

| immediate 
| parameter 


DO| 
jl 
x _ 




1 1 




T 

| immediate 

j parameter 

_x 


DO| 
1 10 

L _ 




1 * 

|) 




T — 

| parameter 

-+ 

| 00 

L 


T 
__X 

j 0000 

J. 




1 » 




— r — — — T 
| integer var.|p(I) 

4. — J- 




| = 




T 

| immediate 
| parameter 

_4- — _ _ 


T 

DO| 
—4. 




1 1 




T 

| immediate 

j parameter 

j. 


T 
DO| 
|15 

X 




1 1 




T 

| immediate 

| parameter 

_j _ 


DO| 
|1 
x_ . 




|) 




| 00 

L _ _ _ 


|0000 
4. 




jend 


mark 


| 00 


T 

| internal stmt 


no. j 
j 



Figure 42. Example of Input to Phase 14 



V~ T~ T 1 

| adjective | mode/type | pointer field | 
jcode field j field | (2 bytes) | 
| (1 byte) | (1 byte) | j 

i- — 4- 4-— — J 


r T T 1 
| non- | | | 
j formatted (sequential j j 
| write (access I/O |0000 j 

h + x 4 

| J integer | | 
|( |variable jaddress(N) | 
L - 4. 4. - 4 


r T T 1 
|end mark *! 00 |0000 | 

|. x x J 

| implied DO|00 |0000 | 
,. X X 4 

| | integer | | 
j, j variable j address (I) j 
l _ 4__ 4. 4 


r t — T 1 
| | immediate DO| | 
| = j parameter j 1 | 

h + + 4 

| | immediate DO | | 
j, | parameter j 15 | 

^ X X 4 

| | immediate DO| | 
j , j parameter j 1 | 

|. + + 4 

| implied DO|00 | 0000 | 

^ + + 4 

| | integer | | 
|, | variable (address (J) j 
F + + 4 

| | immediate DO | | 
j = j parameter j 1 j 
u 4. - - X 4 


r T t 1 
| | immediate DO | | 
j, | parameter j 10 j 

^ X X J 

| | immediate DOj | 
j , j parameter 1 1 j 
^ x x j, 

| begin I/O | 00 |0000 | 
h x x 4, 

|SAOP | 00 j offset | 
f X + 4 

|p (subscript) |p (dimension) | 

L _ L _ 4 


r T T 1 

| | real | | 
|( (subscripted | address (A) | 
| | variable | | 
L 4. _ 4. 4 


r T T — 1 
jend DO j 00 j 0000 j 
^ + + J 

|end DO | 00 J0000 j 
h + + 4, 

jend I/O J00 J0000 j 
I- - 4- 4- -1 


r T T 1 
| | (internal ( 

(end mark (00 j statement j 
j j | number | 
l x x_ _ _4 


r — — — — 1 

| 1 An end mark is inserted prior to the I/0| 
j list. This allows Phase 20 to treat thej 
j I/O list as a separate statement. j 

L_ J 



Figure 43. Example of Output from Phase 14 
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MODIFICATION OF COMPUTED GO TO STATEMENTS: 
During Phase 14 processing, a count of the 
number of statement numbers in the computed 
GO TO statement is inserted into the inter- 
mediate text for that statement. This 
simplifies the processing of this inter- 
mediate text for the following phases. The 
intermediate text is rearranged so that the 
word containing the integer variable pre- 
cedes the count word. 



Figure 44 illustrates the intermediate 
text input to Phase 14 for the following 
computed GO TO statement. 



GO TO (11,11,42,23,99),! 



| adjective code | mode/ type | pointer | 
j field | field | field j 
j (1 byte) | (1 byte) | (2 bytes) j 
,. + + 4, 

j computed GO TO | 00 | 0000 | 
j. + + -i 

| ( j statement | p(ll) | 
j j number j j 
L_ __ J. _ J. J 


r — -j. - -j. — .j 

| , | statement | p(ll) | 
j | number j j 
|. + + 4. 

| , | statement | p(42) | 
j j number j j 
j. + x 4, 

| , | statement | p(23) | 
j j number j j 
,. + + 4, 

| , | statement | p(99) | 
| j number j | 
J. + 4, 4 

| ) | 00 | 0000 j 
,. 4, + 4 

| , | integer | p(I) | 
| | variable j j 
j. + + 4. 

| end mark | 00 | internal | 
j j j statement | 
| | | number j 

L _ __ -J. ____ X 4 



Figure 44. Intermediate Text Input to 
Phase 14 for a Computed GO TO 
Statement 



Figure 45 illustrates the output of 
Phase 14 for the above computed GO TO 
statement. 



r- — -t - - -t i 
| adjective code | mode/type | pointer | 
| field j field | field | 
j (1 byte) | (1 byte) | (2 bytes) | 
(. + + 4 

| computed GO TO | 00 | 0000 | 

| , | integer j a (I) j 
| j variable j | 
1.--- 4— - 4-- 4 


r - — — -f— — -f - -j 
| count | 00 | 5 | 
|. + + 4, 

| ( | statement | p(ll) | 
j | number j j 

I _ _ --4- 4-- 4 


r T T 1 

| , | statement | p(ll) | 
j j number j j 
(. + + 4. 

| , | statement | p(42) | 
| | number j j 

j. + + 4, 

j , | statement | p(23) | 
j j number j | 
j. + + 4. 

| , | statement | p(99) | 
j j number j j 

|. + + 4 

| ) | 00 | 0000 | 
l_ _ _ 4. 4. 4 


r t T — 1 
| end mark | 00 | internal | 
j j j statement j 
j j j number j 



Figure 45. Intermediate Text Output From 
Phase 14 for a Computed GO TO 
Statement 



MODIFICATION OF RETURN STATEMENT INTERMEDI- 
ATE TEXT; If a RETURN statement appears 
within a main program. Phase 14 modifies 
the adjective code field so that a STOP is 
indicated. If the RETURN statement is not 
within the main program, no modification is 
made. 



Phase 15 



During Phase 15 processing, the follow- 
ing intermediate text modifications are 
made: 

• Replacement of adjective codes and 
mode/ type codes. 

• Reordering of intermediate text for 
arithmetic expressions. 

• Reordering of intermediate text for 
DEFINE FILE statements. 
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REPLACEMENT OF ADJECTIVE 



CODES 



AND 



MODE/TYPE CODES : During the processing of 
arithmetic expressions. Phase 15 replaces 
the adjective codes (within the intermedi- 
ate text entries for arithmetic 
expressions) by actual machine operation 
codes. Phase 15 also assigns registers to 
the operands in arithmetic expressions 
(when required) ; the corresponding register 
numbers are inserted in the mode/type 
fields of the intermediate text that rep- 
resents those expressions. 



The result of the above modification is 
a transformation of the intermediate text 
entries for arithmetic expressions into a 
form that closely resembles the RX instruc- 
tion format. 

The following figures indicate the 
replacement of adjective codes by machine 
operation codes, and the replacement of 
mode/type codes by registers. 

Figure 46 illustrates the intermediate 
text input to Phase 15 for the following 
arithmetic statement. 



PRI = +VATE - VAR 



Figure 47 illustrates the intermediate 
text output from Phase 15 for this state- 
ment. 



adjective 
code field 
(1 byte) 



arithmetic 
statement 



ST 



end 
mark 



mode/type 

field 
(1 byte) 



■T 1 

| pointer 
| field 
| (2 bytes) 

■+- 



real variable |a(PRI) 



reg . #3 j variable j a (VATE) 



reg.#3 j variable j a (VAR) 



reg. #3 1 variable | a (PRI) *■ 



00 



| internal 
J statement 
j number 



A The pointer field contains the address 
of the resultant field of the arithmetic 
statement. 

Figure 47. Intermediate Text Output From 
Phase 15 for an Arithmetic 
Statement 



adjective 
code field 
(1 byte) 



arithmetic 
statement 



unary plus 



| 

end 
mark 



mode/type 

field 
(1 byte) 



real variable 



00 



real variable 



real variable 



00 



pointer 

field 
(2 bytes) 



a(PRI) 



0000 



a (VATE) 



a (VAR) 



internal 

statement 

number 



Figure 46, 



Intermediate Text 
Phase 15 for an 
Statement 



Input to 
Arithmetic 



Note: The first operand VATE, is loaded 
into register #3. The second operand, VAR, 
is subtracted from VATE. The result is 
stored in the resultant field, PRI. 

In addition, registers are assigned and 
are inserted in the mode/type field of the 
following: 

• Intermediate text entries for exponen- 
tiation. 

• Intermediate text entries for in-line 
functions, referenced subprograms, and 
statement function calls. 

• Intermediate text entries for subscript 
expressions. 



Figure 48 illustrates these modifica- 
tions to the intermediate text. 
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Input To Phase 15 



+~ 



Output From Phase 15 



For: 



Phase 15 assigns: 



exponentiation. 



r t t 1 

| | mode/ type | | 

I** | information J a (POWER) j 
,. _ + + j| 

| 1 byte | 1 byte j 2 bytes j 
l j. x J 



a register to contain the result of the 
required library subprogram execution. 



** 



*T T T 

| | result | 
| j reg j a (POWER) 
.4. x 4- 



1 byte | 
x. 



1 byte | 2 bytes | 
jl J 



in-line functions. 



r t t 1 

| in-line | | code num- | 

| function j not used j ber of in- j 
| adj. code | jline f unct. j 

I I I I 

|F( | not used | a (argument) | 

I I I I 

,. + + j, 

j 1 byte j 1 byte |2 bytes j 



one or two registers (depending 
on the specific in-line function) 
to be used as argument registers. 
The register specified in the Rl 
field is used as the result register. 

r t t t 1 

I III I 

I | | not | | 

| load |R1 | used | a ( argument ) | 

j in-line j j jcode num- j 
| function |R2 j Rl jber of in- | 
j adj. code | | jline funct. j 
(. + j. + jj 

j 1 byte j 1 bytej 2 bytes j 
l j. x J 



subscript expressions, 



r t t T 

(subscript | mode/ type j | 

| adj. code j information! offset j 

| 1 byte | 1 byte | 2 bytes | 
l jl x J 



a work register (to be used by 
Phase 20) to aid in the computa- 
tion of the subscript expression. 



r t— 

| subscript | 
j adj. code JO 
j. x_. 

| 1 byte | 
i x_. 



"T T 1 

| work | | 

j reg. {offset j 

.x x J, 

1 byte | 2 bytes | 
x J 



Figure 48. Assignment of Registers by Phase 15 



REORDERING OF INTERMEDIATE TEXT FOR ARITH- 
METIC EXPRESSIONS: Phase 15 reorders the 
intermediate text entries within arithmetic 
expressions so that the object module 
instructions produced by subsequent phases 



are generated according to a hierarchy of 
operators . 

The following figures indicate this 
reordering process. 
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Figure 49 illustrates the intermediate 
text input to Phase 15 for the following 
arithmetic statement. 



DGM = BCR* (WRG+WAR) 



r - — t - t - i 

| adjective | mode/type | pointer | 
jcode field j field | field j 
| (1 byte) | (1 byte) j (2 bytes) | 

l X - - X J 


r T T 1 
| arithmetic! real variable | a (DGM) | 
,. _ X x 1 

|= | real variable | a (BCR) | 
l x x ^ 

!* | 00 | 0000 | 

L X X .j 

| ( | real variable | a(WRG) | 
|. X x 1 

|+ | real variable | a (WAR) | 
L x__ _ i _ i 


|) | 00 | 0000 | 

L X _ X ) 

J end | | internal | 
jmark j 00 j statement! 
j j | number j 

L X X J 



Figure 49. Unordered Intermediate Text for 
an Arithmetic Statement 



Figure 50 illustrates the intermediate 
text output from Phase 15 for this state- 
ment. 



adjective 
code field 
(1 byte) 



arithmetic 



LE 



AE 



ME 
STE 



end 

mark 



mode/type 

field 
(1 byte) 



real variable 



register | variable 
6 j information 



register j variable 
6 | information 



register j variable j a (BCR) 
6 J information 

register | variable I a (DGM) 
6 | information 



00 



pointer 

field 
(2 bytes) 



a (DGM) 



a (WRG) 



a (WAR) 



internal 

statement 

number 



Figure 50. Reordered Intermediate Text for 
an Arithmetic Statement 



REORDERING OF INTERMEDIATE TEXT FOR DEFINE 
FILE STATEMENTS ; Phase 15 reorders the 
intermediate text for DEFINE FILE state- 
ments to facilitate the generation of TXT 
card images for the parameter lists includ- 
ed in those statements. Each parameter 
list is reordered into a three- argument 
format and is considered as a separate 
DEFINE FILE statement. (The parameter 
lists define the format of the direct 
access data sets to be used at 
object-time. ) 



The following figures illustrate the 
reordering process. 



Figure 51 illustrates the input to Phase 
15 for the following DEFINE FILE statement. 



DEFINE FILE 2 (50, 20, L, 12) , 3 (100, 20, U, J3) 



r _ T _ T __ 1 
| adjective | mode/type J pointer | 
j code field j field j field | 
j (1 byte) j (1 byte) | (2 bytes) | 

L _ X — — 4 — — _ J 


r T T 1 
j DEFINE FILE j unit | 2 j 
,. X X 1 

| | integer | | 
j ( j constant j a (50) j 

(. X X .j 

1 * I integer | | 
j j constant j a (20) | 

L X X .| 

| | immediate | | 
j , j constant j L j 

J. X X _ .| 

| | integer | | 
j , j variable j a (12) | 

L X X .| 

| ) | unit | 3 | 

L X X J 


r T T — 1 

| | integer | | 
j , j constant j a (100) j 

|. X X .| 

| | integer | | 
j , | constant j a (20) j 

|. X X H 

| | immediate | | 
j , j constant | U j 
L_ _ x - 4- J 


r — t — T — — 1 

j | integer | | 
| , j variable | a(J3) | 
l x x ^ 

| ) | 00 | 0000 | 

L X X ^ 

j | | internal | 
| end mark j j 00 j statement j 
j | | number | 



Figure 51. Intermediate 

Phase 15 for 
Statement 



Text Input to 
a DEFINE FILE 
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Figure 52 illustrates the output from 
Phase 15 for the statement. 



h- 



adjective 
code field 
(1 byte) 



DEFINE FILE 



00 



80 2 



end mark 



DEFINE FILE 



00 



00 



end mark 



mode/ type 
field 
(1 byte) 



T 1 

pointer 
field 
(2 bytes) 



00 



00 



integer 
constant 



integer 
constant 



integer 
variable 



00 



00 



00 



integer 
constant 



integer 
constant 



integer 
variable 



00 



0000 



0003 * 



a(50) 



a(20) 



a(I2) 



0000 



0000 



0003 



a(100) 



a(20) 



a(J3) 



internal 

statement 

number 



^-The constant 0003 indicates that the 
next three intermediate text words con- 
tain a parameter list. 

a The constant 80 indicates to Phase 20 
that this is not the last parameter list 
in the DEFINE FILE statement. 

3 The constant 00 indicates to Phase 20 
that this is the last parameter list in 
the last DEFINE FILE statement. 

Figure 52. Intermediate Text Output From 
Phase 15 for a DEFINE FILE 
Statement 



Phase 20 



will be discussed by examining a general 
subscript expression as it appears in the 
input to Phase 20 and by examining the 
subscript intermediate text output from 
Phase 20 for this expression. 



SUBSCRIPT INTERMEDIATE TEXT INPUT: 



intermediate text input to Phase 20 
general expression is shown in Figure 53 



r t t 

adjective code | mode/type | pointer 
field | field | field 
(1 byte) | (1 byte) | (2 bytes) 



The 
for a 



adjective code jo jw 

x X_- 



| of f set 



p( subscript) 



jp (dimension) 



OP 



R 



| type | a (variable) 
-X x 



Adjective code contains the adjective 
code for a subscripted variable portion 
of text. 

O contains a zero value. 

W contains a work register assigned by 
Phase 15. 

Offset contains the value of the offset 
portion of the array displacement. 

p (subscript) contains the pointer to sub- 
script information in the overflow table 
for this expression. 

p (dimension) contains the pointer to 
dimension information in the overflow 
table for this expression. 

OP contains the operation code assigned 
by Phase 15. 

R contains a register assigned by Phase 
15. 

Type contains the residual (since it is 
no longer necessary) type information for 
the subscripted variable. 

a (variable) contains the address of the 
subscripted variable. 



Figure 53. Subscript Intermediate 
Input Format 



Text 



Phase 20 optimizes the intermediate text 
entries for subscript expressions. This 
optimization consists of modifying portions 
of existing subscript intermediate text and 
creating new subscript intermediate text 
for literals that are generated during the 
subscript optimization process. The chan- 
ges made to subscript intermediate text 



SUBSCRIPT INTERMEDIATE TEXT OUTPUT: Sub- 
script intermediate text output from Phase 
20 depends on the previous optimization (if 
any) of the subscript expression. Three 
adjective codes are used to indicate the 
different conditions that can be present in 
subscript intermediate text output. These 
conditions are explained in the following 
paragraphs. 



Appendix F: Intermediate Text 121 



SAOP (Subscript Arithmetic Operator) Adjec- 
tive Code; This code indicates that a 
subscript expression has not been previous- 
ly optimized, and that an offset literal 
was not generated for the value resulting 
from the addition of the offset portion of 
the array displacement to the subscripted 
variable address displacement. Subscript 
text output associated with an SAOP adjec- 
tive code is shown in Figure 54. 



r t t 

adjective code | mode/type) pointer 
field | field | field 
(1 byte) | (1 byte) | (2 bytes) 



SAOP 



| N | w | offset 
-X x 4- 



p( subscript) 



|a(Cl*L) 



a(C2*Dl*L) 



|a(C3*Dl*D2*L) 



OP 



-t t T 

j R j X | a (variable) 
-i x x 



SAOP contains an adjective code designat- 
ing the form of the intermediate sub- 
script text. 

N contains the number of dimensions of 
the subscripted variable. 

a(Cl*L), a(C2*Dl*L), and a(C3*Dl*D2*L) 
contain the addresses of the literals 
that combine to form the CDL portion (see 
Appendix G) of the array displacement. N 
determines which addresses must appear. 
For example, if N is 1, only a(Cl*L) 
appears. (If the first literal, C1*L, is 
a power of 2, that power appears instead 
of the address of that literal.) 

X contains the register assigned to the 
subscript expression for computation by 
Phase 20. 



Note: 



All other entries are as defined 



in Figure 53. 



Figure 54. Subscript Intermediate Text 
Output From Phase 20 — SAOP 
Adjective Code 



XOP (Offset Literal) Adjective Code: This 
code indicates that the subscript expres- 
sion has not been previously assigned a 
register and that an offset literal was 
generated for the value resulting from the 
addition of the offset portion of the array 
displacement to the displacement of the 
subscripted variable address. The sub- 
script intermediate text output associated 
with an XOP adjective code is shown in 
Figure 55. 



AOP (Arithmetic Operator Without Subscript) 
Adjective Code: This code indicates that 
the subscript expression has previously 
been assigned a register. The subscript 
intermediate text output associated with an 
AOP adjective code is shown in Figure 56. 



r t t 

adjective code | mode/type 
field | field 
(1 byte) j (1 byte) 



XOP 



N 



W 



p (subscript) 



a(C2*Dl*L) 



OP 



pointer 

field 
(2 bytes) 



a (generated 
literal) 



a(Cl*L) 



a(C3*Dl*D2*L) 



■t t T 

j R | X j a (variable) 
.X x x 



XOP contains an adjective code designat- 
ing the form of the subscript intermedi- 
ate text. 

a (generated literal) contains the address 
of the offset literal generated by Phase 
20. 

Note: All other entries are as defined in 



Figures 53 and 54. 



Figure 55. Subscript Intermediate Text 
Output from Phase 20 — XOP 
Adjective Code 



r t t 

adjective code j mode/type) pointer 
field j field j field 
(1 byte) | (1 byte) | (2 bytes) 



AOP 



•+■ 



| O | B | offset 



OP 



R | X | a (variable) 
X X 



|. X. 

AOP contains an adjective code designat- 
ing the form of subscript intermediate 
text. 

O contains a zero value. 

B contains an indicator. A hexadecimal 
indicates that the actual offset is in 
the offset field. A hexadecimal F indi- 
cates that the address of the generated 
offset literal appears in the offset 
field. 

Note: All other entries are as defined in 



Figures 53 and 54. 



Figure 56. Subscript Intermediate Text 
Output from Phase 20 — AOP 
Adjective Code 
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APPENDIX G: ARRAY DISPLACEMENT COMPUTATION 



Array displacement is the distance 
between the first element in an array and a 
specified element to be referenced from the 
array. To increase compilation efficiency, 
the array displacement is divided into 
portions and computed during different 
phases. 



Before discussing the actual computa- 
tion, it is desirable to understand how an 
element is referenced in a l- f 2- f and 
3-dimensional array. 



ONE DIMENSION 



the first dimension part consists of 
A(l,l), A(2,l), and A(3,l). Note that the 
number of elements in each dimension part 
is the same as the first number (3) in the 
subscript expression used to dimension 
array A. 



Dimension parts are consistent in 
length. Length is determined by multiply- 
ing the number of elements in a dimension 
part by the array element length. The 
resulting value is considered a dimension 
factor for the following discussion. (If 
the element length in array A is 4, the 
dimension factor is 3 times 4, or 12.) The 
dimension factor plays a significant role 
in referencing a specific element in a 
2-dimensional array. 



Assume a 1-dimensional array of five 
elements, expressed as A(5). To reference 
any given element in this array, the only 
factor to be considered is the length of 
each element. The third element, for exam- 
ple, is two element lengths from the begin- 
ning of the array. 



TWO DIMENSIONS 



For a 2-dimensional array, A(3,2), an 
element can no longer be thought of as a 
single array element. Instead, each ele- 
ment in a 2-dimensional array consists of 
the number of array elements designated by 
the first number in the subscript expres- 
sion used to dimension the array. For 
reference, an element in a 2-dimensional 
array will be called a dimension part. For 
example, in the array of A(3,2): 



A(l,l) A(2,l) A(3,1)-t - Dimension Part 

j 



Before discussing how a specified ele- 
ment is referenced, the hexadecimal number 
scheme used to address an array element 
must be considered. The first digit of the 
hexadecimal number scheme (as used in the 
compiler) is zero. The 16 hexadecimal 
digits are: 



0,1,2,3 



, 4,5,6,7,8,9,A,B,C,D,E, 



and F. 



l>A(1,2) A(2,2) A(3,2) - Dimension Part 



Consider that the element A (1,2) is to 
be referenced from the array dimensioned as 
A(3,2). Observation shows one dimension 
part must be bypassed in order to reference 
the specified element. The computation to 
reference this element requires the values 
in the subscript expression (1,2). Each 
number must be decremented by 1 to compen- 
sate for the zero-addressing scheme used by 
the compiler. This leaves an expression of 
(0,1). The second number (1) dictates the 
number of dimension parts to be bypassed in 
order to arrive at the dimension part in 
which the specified element is located. 
Once this dimension part is found, the 
first number (0) indicates the number of 
elements in that dimension part that must, 
be bypassed to reference the specified 
element. 
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THREE DIMENSIONS 



The same reasoning can be projected into 
a 3- dimensional array. For a 3-dimensional 
array,, A (3,2 ,3), an element can neither be 
considered a single array element, nor 
thought of as a dimension part. Each 
element in a 3-dimensional array consists 
of the number of dimension parts designated 
by the second number in the subscript 
expression used to dimension the array. 
For reference, therefore, an element in a 
3-dimensional array will be called a dimen- 
sion section. For example, in the array 
A(3,2,3) : 



Dimension Section 
A(l,l,l) A(2,l,l) A(3,l,l)-, 



- Dim. Part 



L>A(1,2,1) A(2,2,l) A(3,2,l)-, - Dim. Part 



j Dimension section 

L>A(1,1,2) A(2,l,2) A(3,l,2)i 



- Dim. Part 



L>A(1,2,2) A(2,2,2) A(3,2,2) 1 - Dim. Part 



(Dimension Section 

L>A(1,1,3) A(2,l,3) A(3,1,3)t - Dim. Part 

I 
r j 

«->A(l,2,3) A(2,2,3) A(3,2,3) - Dim. Part 



the first dimension section consists of the 
dimension part beginning with A (1,1,1) and 
the dimension part beginning with Ad, 2,1). 
In this example, we have three dimension 



sections, as specified by the third number 
in the subscript expression used to dimen- 
sion the array. 



Again, the length of the dimension sec- 
tions is consistent. The length, in this 
case, is determined by multiplying the 
number of elements in a dimension part by 
the number of dimension parts by the array 
element length. The resulting value is 
considered a dimension multiplier for the 
following discussion. (If the element 
length in array A is 4, the dimension 
multiplier is 3 times 2 times 4 or 24.) 



Consider that the element A (2,2,3) is 
to be referenced from the array dimensioned 
as A (3,2,3). Observation shows two dimen- 
sion sections, one dimension part, and one 
array element must be bypassed in order to 
obtain the specified element. The computa- 
tion to reference this element requires the 
values in the subscript expression (2,2,3). 
Each number must be decremented by 1 to 
compensate for the zero-addressing scheme 
used by the compiler. This leaves an 
expression of (1,1,2). The third number 
(2) indicates the number of dimension sec- 
tions to bypass in order to arrive at the 
dimension section in which the specified 
element is located. The second number (1) 
indicates the number of dimension parts, 
within the referenced dimension section, 
that must be bypassed to arrive at the 
dimension part in which the specified ele- 
ment is located. Once this dimension part 
is found, the first number (1) indicates 
the number of elements in that dimension 
part that must be bypassed to reference the 
specified element. The preceding example 
is illustrated in Figure 57. 



This concept of how a specified element 
is referenced from an array is generalized 
in the following text. 



A(2,2,3) 

! 

| Zero-addressing adjustment 
V 
A(l,l,2) 



j •- > 2 dimension sections 

I 

»■ > 1 dimension part 

-> 1 array element 

Figure 57. Referencing a Specified Element in an Array 



l : 

L 




Must be bypassed to 
obtain specified element 

j 
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General Subscript Form 



( Jl-1) *L+ ( J2-1) *D1*L+ ( J3-1) *D1*D2*L 



The general subscript form 
(C1*V1+J1,C2*V2+J2, C3*V3+J3) refers to some 
array. A, with dimensions (Dl, D2, D3) . 
The required number of elements is speci- 
fied by (C1+V1+J1) ; (C2+V2+J2) *D1; and 
(C3+V3+J3) *D1*D2, representing the first, 
second, and third subscript parameters mul- 
tiplied by the pertinent dimension informa- 
tion for each parameter. Therefore, the 
required number of elements for the general 
subscript form is: 



(C1*V1+J1) + (C2+V2+J2) *D1+ (C3*V3+J3) *D1*D2 



is known as the offset portion and is 
calculated by Phase 10E. The offset is 
calculated using the following formulas for 
1-, 2-, and 3- dimensional arrays. 



0FFSET=[J1-13 * Length 

OFFSET= [ (Jl-1) + ( J2-1) *D13 

♦Length 

OFFSET= [ (Jl-1) + ( J2-1) *D1 

+ ( J3-1) *D1*D2] * Length 



1- dimens ional 
2-dimensional 
3- dimens ional 



Array Displacement 



The array displacement for a subscript 
expression, specifically stated, is the 
required number of array elements multi- 
plied by the array element length. There- 
fore, the array displacement is: 



[ (C1*V1+J1) + (C2+V2+J2) *D1+ 

(C3*V3+J3)*D1*D2)]*L 

Because of the zero-addressing scheme, the 
displacement is: 

(C1*V1+J1-1) *L+ (C2+V2+J2-1) *D1*L+ 
(C3*V3+J3-1) *D1*D2*L 

This expression can be rearranged as: 

(C1*V1*L+C2*V2*D1*L+C3*V3*D1*D2*L)+ 
t(Jl-l)*L+(J2-l)*Dl*L+(J3-l)*Dl*D2*L)] 

The first portion of the array displace- 
ment is referred to as the CDL (constant, 
dimension, length) portion and is derived 
from: 

C1*V1*L+C2*V2+D1*L+C3*V3*D1*D2*L 

VI, V2, and V3 are the variables of the 
expression and cannot be computed until the 
execution of the object module. This 
leaves the following components, which con- 
stitute the CDL portion of the displace- 
ment : 

C1*L is the first component, 
C2*Dl*L is the second component, and 
C3*D1*D2*L is the third component. 

The second portion of the array dis- 
placement: 



This calculation is performed and the 
result is entered in the offset field of 
the intermediate text entry for that sub- 
script. Refer to Appendix F for the inter- 
mediate text format. 

The CDL components are calculated during 
Phase 20. If the CDL component is a power 
of 2, that power replaces the offset field 
in the intermediate text entry. If the CDL 
component is not a power of 2, a literal is 
formed and assigned an address (by Phase 
20). The address of the literal is then 
entered in the offset field of the inter- 
mediate text entry. Refer to Appendix F 
for the intermediate text form and content. 

Phase 25 combines the CDL components, 
the variables, and the offset to produce 
the array displacement. The procedure is 
as follows: the first component of the CDL 
multiplied by the first variable of the 
subscript expression (C1*L)*V1; plus the 
second component of the CDL multiplied by 
the second variable of the subscript 
expression (C2*D1*L) *V2, plus the third 
component of the CDL multiplied by the 
third variable of the subscript expression 
(C3*D1*D2*L)*V3; plus the offset: 

(J1-1)*L+(J2-1)*D1*L+(J3-1)*D1*D2*L. 



Note: Table 26 illustrates the maximum 
sizes of the various arrays. 



Table 26. Array Size Maximums 



| Array Type | Maximum Number | 
| J of Elements j 
i— 4- — — - J 


r T 1 
| Integer | 32767 | 

L _ i _ J 


| Real | 32767 | 
j. + .| 

| Double- | j 
| Precision j 16383 J 
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APPENDIX H: RESIDENT TABLES 



The compiler uses the following resident 
tables : 

• The dictionary. 

• The overflow table. 

• The segment address list (SEGMAL) . 

• The patch table. 

• The blocking table (resident only for 
PRFRM compilations). 

• The BLDL table (resident only for PRFRM 
compilations) . 

• The reset table (resident only for 
PRFRM compi la t i ons ) . 



The dictionary contains information 
about variables, arrays, constants, data 
set reference numbers, etc., used in the 
source module. The overflow table contains 
all dimension, subscript, and statement 
number information within the source 
module. SEGMAL is used for main storage 
allocation within the compiler. The patch 
table contains information for modifying 
compiler components. The blocking table 
contains the information necessary for 
deblocking compiler input and blocking com- 
piler output for PRFRM compilations. The 
BLDL table contains the information neces- 
sary for transferring control from one 
component of the compiler to the next for 
PRFRM compilations. The reset table 
(RESETABL) is used to determine which, if 
any, of the record counts for SYSUT1 and 
SYSUT2 must be reset. 



THE DICTIONARY 



which indicates the first entry in each 
chain. There are 15 chains, used for 
various entries, as follows: 



Eleven are organized on the basis of 
length of the symbol being entered 
(e.g., DO has a length of 2, END has a 
length of 3, etc.). The first chain is 
for entries of length 1, the second is 
for entries of length 2, the third is 
for entries of length 3, and so on. 



These chains contain entries for res- 
erved words (chains 2-11), in-line 
functions, variables, and arrays. 



• One chain for real constants. 

• One chain for integer constants. 

• One chain for integer data set ref- 
erence numbers. 

• One chain for double- precis ion con- 
stants . 



Phase 7 Processing 



Phase 7 enters all reserved words (words 
that indicate a specific FORTRAN statement) 
and the dictionary index into the dictiona- 
ry. 



Figure 58 illustrates the dictionary 
after it is constructed by Phase 7. 



Phase 5 allocates main storage for the 
dictionary. The dictionary (constructed by 
Phases 7, 10D, and 10E) is used and modi- 
fied by Phase 12 in address assignment, and 
is further used by Phase 14 when addresses 
from the dictionary replace pointers to the 
dictionary in the intermediate text entries 
(refer to Appendix F) . For SPACE compila- 
tions, Phase 14 frees the dictionary area 
of storage for use by subsequent phases. 



The dictionary is organized as a series 
of chains related by the dictionary index. 



Phases 10D and 10E Processing 



Additions to the dictionary occur as 
entries are made to the various chains 
during Phases 10D and 10E processing. To 
enter an item in the dictionary, the perti- 
nent chain is located via the dictionary 
index. The chain is searched until the 
last entry is found. The current end-of- 
chain indicator is replaced with a pointer 
to the new entry; the new entry is then 
marked as the end of the chain. 
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For example, assume the variable ABC is 
to be entered in the dictionary. ABC 
belongs in the third chain of the diction- 
ary (length 3). Using the dictionary 
index, the first entry of the chain for 
length 3 is obtained. Assume that Figure 
58 indicates the condition of the diction- 
ary at this time. The chain for length 3 
is searched for the last entry (the entry 
for DIM) , which is modified to appear as : 



The entry for ABC appears as: 



lend of 
J chain 
l 



| entry for 
JABC 
.x 



r t 

| pointer to the entry | entry for 
I for ABC | DIM 

L X 



When the dictionary and overflow table 
overlap, a message is issued; no new 
entries are made; and compilation proceeds. 



DICTIONARY INDEX 



r- 

r+- 



r++ 
r+H 



end of the chain of length 1 

pointer to the first entry in the chain of length 2 

pointer to the first entry in the chain of length 3 

pointer to the first entry in the chain of length 4 

pointer to the first entry in the chain of length 5 

pointer to the first entry in the chain of length 6 

pointer to the first entry in the chain of length 7 

pointer to the first entry in the chain of length 8 

pointer to the first entry in the chain of length 9 

pointer to the first entry in the chain of length 10 

pointer to the first entry in the chain of length 11 
end of the chain for integer constants 
end of the chain for real constants 
end of the chain for data set reference numbers 
end of the chain for double-precision constants 



There are several chains that have no entries when the dictionary is constructed 
during Phase 7. That is, there are no reserved words of length 1, and no entries 
would be made in the data set reference number chain or constant chains. 



j pointer to j entry for j 
| the entry | DO j 
| for GO j j 



| pointer to | entry for j 
jthe entry j GO j 
| for IF | | 



end of 
chain 



■T 1 

| entry for | 
I IF I 



\ ^ T 1 

| pointer to | entry for | 
jthe entry j END j 
j for ABS j | 



\ — £=^=n- 

| pointer to | entry for | | 

jthe entry j ABS j j 

| for DIM | | | 

l i. j i. 



end of 
chain 



-T 1 

| entry for | 
I DIM I 



end of 
chain 



'T 1 

| entry for | 
j SUBROUTINE j 

-A J 



Figure 58. 



end of j entry for j 

chain | EQUIVA- j 

| LENCE j 

x J 

The Dictionary as Constructed by Phase 7 



r *■ ■, 

I Note : See Figure 61 for| 
jthe general format of a| 

| dictionary entry. | 
l j 
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Phase 12 Processing 



During Phase 12 processing, addresses 
are assigned to the symbols entered in the 
first six chains of the dictionary. In 
assigning these addresses. Phase 12 uses 
the contents of the dictionary entries. 
The addresses replace: (1) the pointers to 
following entries in the dictionary, and 
(2) the end-of -chain indicators. To ensure 
that the chain is not broken, the chain is 
continued by modifying the pointer to the 
entry just assigned an address. Figures 59 
and 60 illustrate two cases of the "before" 
and "after" in removing an entry from a 
dictionary chain. Figure 59 indicates 
removal of an entry from the end of the 



chain. Figure 60 indicates removal of an 
entry from the middle of the chain. 



Phase 1H Processing 



During Phase 1H processing, each inter- 
mediate text pointer to a dictionary entry 
is replaced by information contained in 
that dictionary entry (e.g., a relative 
address assigned by Phase 12). Refer to 
Appendix F for examples of this intermedi- 
ate text modification. 



V 



71- 



"before" an address j pointer to the entry | entry for DIM | | end of chain j entry for ABC j 

is assigned to the j f or ABC j j j | | 

variable ABC | j | j j | 

i j. j l j. j 



"after" an address 
is assigned to the 
variable ABC 



end of chain 



•t 1 r t 1 

I II I I 

| entry for DIM | | assigned ad- | entry for ABC | 
| | | dress of ABC| j 

I II I I 

.X J L X J 



Figure 59. Removing an Entry From the End of a Dictionary Chain 



"before" an address 
is assigned to 
the variable ABC 



L-.L- T 

pointer to | entry | 
the entry j for j 
for ABC j AAA | 

L X J 



LI 



T T 

pointer to | entry J 
the entry j for | 
for CCC | ABC j 
x J 



T 1 

pointer to j entry | 
the entry j for j 
for DDD | CCC | 
j. j 



"after" an address 
is assigned to 
the variable ABC 



1 C 



■T 1 

| pointer to | entry | 
| the entry j for j 
| for CCC | AAA j 
l x J 



r t 1 

| assigned | entry | 
j address of | for | 
j ABC | ABC | 

L x J 



v-i ; 

| pointer to | entry J 
j the entry j for | 
| for DDD | CCC | 
l j. j 



Figure 60. Removing an Entry From the Middle of a Dictionary Chain 
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Dictionary Entry Format 



The entries to the dictionary may vary; 
however, they all have the same general 
format. Figure 61 indicates this general 
format. 



r T T T T T 1 

I chain | usage | mode/ | image | address | size | 
| field | field | type |field| field | field | 
I I |field| | | | 

| 2 |1 |1 |1-11 |2 |2 | 
| bytes | byte | byte | bytes | bytes | bytes | 
l J. J. x j. ± J 

Figure 61. General Format of a Dictionary 
Entry 



• Reserved words — to indicate the posi- 
tion of the displacement of the proc- 
essing routine for that reserved word 
in the Phase 10D or Phase 10E Routine 
Displacement Table (see Appendix I) . 

• In-line functions — to indicate the 
code value used within the compilation 
for that in-line function. 

• Arrays — to indicate the displacement 
within the overflow table of the dimen- 
sion information for that array. 



SIZE FIELD: The size field is present for 
the dictionary entries that represent 
arrays. It indicates the size of the 
array. 



Each field contains specific information as 
indicated below: 



CHAIN FIELD: The chain field is used to 
maintain the linkage between the various 
elements of the chain. It either contains 
the relative pointer to the next entry or 
indicates that its associated entry is the 



last entry in the chain. 



USAGE FIELD: 



The 



usage field is divided 

into eight subfields. Each subfield is one 
bit long and is numbered from through 7, 
inclusive. Figure 62 indicates the func- 
tion of each subfield in the usage field. 

MODE/TYPE FIELD: This field is divided 
into two parts (each four bits long). The 
first four bits are used to indicate the 
mode of an entry, while the last four bits 
are used to indicate the type. For exam- 
ple, a real quantity has the mode 7; 
therefore, the mode field for ' a real is 
0111 (the bit configuration for 7). Simi- 
larly, a subscripted variable has the type 
C; therefore, the type field for a sub- 
scripted variable is 1100 (the bit configu- 
ration for C) . The mode/ type field for a 
real subscripted variable is 01111100. The 
various mode/type combinations possible are 
indicated in Figure 63. 



IMAGE FIELD : 



The image field contains the 
image of the symbol. The 

length 



appropriate 

length of the symbol determines the 

of the field. 



ADDRESS FIELD: The address field is pre- 
sent in dictionary entries for: 



All fields are present in each diction- 
ary entry, except the address field and the 
size field. The fields and the phases that 
enter information into the fields are indi- 
cated in Figure 64. 



r - — t — - - i 
| Usage field | Function of the subfield | 
| subfield | | 

l 4- - - - -4 


l T 1 

j Bit | Indicates if the mode of the| 
| j entry has been defined j 
|. + 4, 

| Bit 1 | Indicates if the type of thej 
j j entry has been defined j 
L _ x _ J 


r — T — — 1 
| Bit 2 | Indicates if the entry is in| 

j | COMMON | 

L J. _ J 


r T — 1 
j Bit 3 | Indicates if the entry is | 
j | equated j 

L ±_ _J 


r T — — 1 

| Bit 4 | Indicates if the entry is | 
j | assigned an address j 
|. + 4, 

| Bit 5 | Indicates if this is the| 
j j entry for the root of an | 
j (EQUIVALENCE group (see Phase | 
I 1 12) | 
j. + 4. 

| Bit 6 | Indicates if the entry rep- | 
j j resents double- precis ion | 

|. + 4 

| Bit 7 (Indicates if the entry is for| 
j j an in-line function or anj 
j j external reference. j 



L 

Figure 62. 



Function of Each Subfield in 
the Dictionary Usage Field 
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* T 

HIGH\W 



I I I I I I I III I 

statement J junitj j j^-immediate j j 1 1 sub- j x dummy 
number j j III constants j j | program j subprog. 



5 
inte- 
ger 



6 
double 
pre- 
cision 



7 
real 



|A 


|B 


|C 


|D 


|E 


|F 




+- 


-+— 


f~+" 


4- 


4- 


H 


+~ 


4— 


+— 


f— 


-+- 


4- 


4 


+" 


-+— 


+~+- 


4- 


4- 


4 


1 3. 


1 s. 

|3 
ju 
j ir. 


I s 
ju 

j s 

| c 
jr 
ji 

IP 
|t 


|d 

|u 
jm 
jm 

\y 

1 s 

ju 

l*> 

1 s 

c 

jr 
i 

IP 
jt 










|m 


1 e 


| e 




|d 






Iy 


|d 


d 




|u 
jm 




1 V 


| V 


| V 


| V 




|m 




|a 


|a 


1 a 


a 




|y 




|r 


|r 


|r 


r 








| i 


| i 


i 


i 


|a 


1 a 




|a 


|a 


a 


a 


|r 


1 r 




|t> 


|b 


|b 


|b 


|r 


1 r 




|1 


|1 


|1 


|1 


|a 


|a 




1 e 


1 fe 


|e 


e 


|y 


|y 





^Subject to change after Phases 10D and 10E 

L 



Figure 63. The Various Mode/Type Combinations 



k: — 

I ^ 



x 



I 

| Entry type 



|. ^ x x x x x x 1 x 1 T + + + ., 



| Reserved word 



I. + + — + — + — + — + — + — + — + — + — + — + + + ^ 



| In-line function 



| Variable 
I 



| Constant 



Chain 
field 



10D 
10E 



10D 
10E 



Usage field 



h + 1 + + + + + 1 + + + + + + H 



10D 
10E 



10D 
10E 



7 I 



7 I 



10D|10D 
10E| 



10D| 
10EI 



10D 



^ + + + + + + + + + + + + + + ., 

| Array j 10D j 10DJ 10DJ 10D| 10DJ | 12 j 12 |10D|10D |10D j 10D | 10D | 10D 

| j 10E | I | | | | | |10E|10E |10E j 10E 

^ + + + + + + + + + + + + + + ^ 



12 



12 



-| Mode/Type 
field 



10D 
10E 



10D 
10E 



10E 



10D 
10E 



10E 



Image 
field 



10D 
10E 



10D 
10E 



Address 
field 



Size 
field 



^ + + + + + + + + + + + + + + ^ 

|DSRN | 10E |10E|10E| | | | | | | | 10E | 10E | | | 
L X X X X X X X X X X X X X X J 

Figure 64. Phases That Enter Information Into Specific Fields of a Dictionary Entry 
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THE OVERFLOW TABLE 



Phase 5 allocates main storage for the 
overflow table. The overflow table is 
constructed by Phases 7, 10D, and 10E. The 
overflow table is used by: 

• Phase 12 — to modify subscript 
entries, and to reserve storage for the 
branch list table for referenced state- 
ment numbers. 

• Phases 14 and 15 — for verifying that 
labels are referenced correctly. 

• Phase 20 — for subscript optimization. 

• Phase 25 — for the construction of 
object module coding. 



Organization of the Overflow Table 



The overflow table is organized as a 
series of chains related by the overflow 
index. The overflow index indicates the 
displacement of the first entry in each 
chain relative to the beginning of the 
table. There are 11 chains, used for 
various entries, as follows: 

• Three chains are organized for the 
dimension information of an array; that 
is, for 1-, 2- f and 3-dimensional 
arrays . 

• Three chains are organized for sub- 
script information; that is, for 1-, 
2-, and 3-dimensional subscripts. 

• Five chains are organized for statement 
number information. All statement num- 
bers ending in and 1 are entered in 
the first chain. The remaining chains 
handle statement numbers ending in 2 
and 3, 4 and 5, 6 and 7, and 8 and 9, 
respectively. 



Construction of the Overflow Table 



Phase 5 allocates storage for the over- 
flow table. Because there are no reserved 
words entered in the overflow table as in 
the dictionary, only the overflow index is 
actually constructed by Phase 7. The index 
contains the end-of-chain indicator for 
each chain, as no entries exist in any 
chain at this time. Figure 65 indicates 
the overflow table as it appears after it 
is constructed by Phase 7. 

Phases 10D and 10E construct all entries 
to the overflow table. Each entry is 
entered in an overflow table chain; e.g., 
assume the 1- dimensional array ARRY1 is the 
first array entered in Phase 10D. The 
first overflow index entry is modified to 
contain: 



r 1 

| pointer to the dimension entry for ARRY1 | 
l J 



The overflow table entry (in the first 
array chain) appears as : 



| end of chain 

L 



| entry for ARRY1 

-X 



When the next 1-dimensional array, ARRY2, 
is entered in the overflow table, the entry 
for ARRY1 is modified as follows: 

r t 1 

| pointer to the entry | entry for ARRY1 | 
| for ARRY2 | | 

L J. J 

and the entry for ARRY2 appears as: 

r t 1 

| end of chain | entry for ARRY2 | 
l jl J 

The entries to other chains are made in 
like manner during Phase 10D and the Phase 
10E processing. 



end of chain for 
1-dimensional arrays 



information on 



end of chain for 
2 -dimensional arrays 



information on 



end of chain for 
3-dimensional arrays 



information 



on 



end of chain for information 
1-dimensional subscripts 



on 



end of chain for information 
2-dimensional subscripts 



on 



end of chain for information 
3-dimensional subscripts 



on 



end of chain for information on 
numbers ending in or 1 



statement 



end of chain for information on 
numbers ending in 2 or 3 



statement 



end of chain for information on 
numbers ending in 4 or 5 



statement 



end of chain for information on 
numbers ending in 6 or 7 



statement 



end of chain for information on 
numbers ending in 8 or 9 

i 

Figure 65. The Overflow Table 
Constructed by Phase 



statement 



Index as 
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Use of the Overflow Table 



Phase 12 modifies the statement number 
chains when the branch list table for 
statement numbers (refer to Appendix J) is 
prepared initially by Phase 12. The chain 
field is replaced by a number that 
indicates the position the statement number 
has in the branch list table. Phase 12 
also replaces the chain field in each 
overflow table entry for a subscripted 
variable with the relative address assigned 
to that variable. 

Phases 14 and 15 use the overflow table 
to verify that labels are referenced cor- 
rectly. 

Phase 20 uses the information about 
subscripted expressions in performing its 
function of subscript optimization. This 
information is obtained via a pointer, in 
the intermediate text, to the pertinent 
overflow table entry (in a subscript 
chain) . 



r t t 1 

| chain | 1 | length | 

| chain | 2 | length |D1* length | 

| chain | 3 | length |Dl*length|Dl*D2* length) 

| 2 | 2 | 2 | 2 | 2 | 
| bytes | bytes | bytes | bytes | bytes | 
i l x j. j. J 

Figure 66. Format of Dimension Information 
in the Overflow Table 



The fields of a dimension entry contain 
the following information: 

• The first field contains the displace- 
ment (relative to the beginning of the 
overflow table) of the next element in 
the chain. 

• The second field is a digit, either 1, 
2, or 3, to indicate whether one, two, 
or three fields will follow. This is 
the same as the number of dimensions. 



Phase 25 uses the branch list table 
number, assigned by Phase 12, to determine 
the position of a statement number in the 
branch table. (Phase 25 can then insert 
the object-time address, associated with 
the statement number, in the table.) The 
number is obtained via a pointer, in the 
statement number intermediate text entry, 
to the overflow table. 



• The next field is of the form: 

r t t t 

j L |D1*L |D1*D2*L | 

| 2 bytes |2 bytes |2 bytes | 
l j. ± j 

where : 



Overflow Table Entry 



An entry in the overflow table has one 
of three formats: 



Dl*L and Dl*D2*L are optional fields 
depending on the dimension. 

L indicates the length of an element in 
words (e.g., 1 for integer or real 
quantities and 2 for double-precision 
quantities) . 



1. Dimension. 

2. Subscript. 

3* Statement number. 



Dl represents the value of the first 
dimension of the array. 

D2 represents the value of the second 
dimension of the array. 



DIMENS ION ENTRY : A dimension entry is 
formed for each array. An array may be 
defined as: 



1- dimensional, e.g. 
2- dimensional, e.g. 
3-dimensional, e.g. 



ARRAY (Dl) . 
ARRAY (Dl,D2). 
ARRAY (D1,D2,D3). 



One- dimensional arrays are entered in 
the first dimension chain of the overflow 
table, 2- dimensional arrays in the second, 
and 3-dimensional arrays in the third. The 
formats for the entries of 1-, 2-, and 
3-dimensional arrays are indicated in Fig- 
ure 66. 



SUBSCRIPT ENTRY: A subscript entry is 
formed for each subscripted variable. A 
subscripted variable may be defined as : 

• 1 -dimensional, e.g., A(I) 

• 2- dimensional, e.g., A(I,J) 

• 3-dimensional, e.g., A(I,J,K) 

One-dimensional subscripts are entered 
in the first subscript chain of the over- 
flow table, 2-dimensional subscripts in the 
second, and 3-dimensional subscripts in the 
third. The formats for the entries of 1-, 
2-, and 3-dimensional subscripts are illus- 
trated in Figure 67. 
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r t t 1 

chain | CI | pointer to VI in | 
I j the dictionary | 



chain j CI | pointer to VI in j C2 

j | the dictionary j 
x x x 



j pointer to V2 in j 

| the dictionary j 

.x ., 



T T T T 1 T 1 

chain | CI | pointer to VI in | C2 | pointer to V2 in | C3 (pointer to V3 in | 
j | the dictionary j jthe dictionary | | the dictionary j 

| 2 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes | 
l x x x x x x j 

Figure 67. Format of Subscript Information in the Overflow Table 



The fields of a subscript entry contain 
the following information: 



• The second field is a usage field. The 
usage field bits and their meanings are 
illustrated in Figure 69. 



The first field contains the displace- 
ment (relative to the beginning of the 
overflow table) of the next element in 
the chain. 



The second and third, fourth and fifth, 
and sixth and seventh fields represent 
the first, second, and third dimensions 
of the subscript. The explanation and 
use of CI, VI, C2, V2, C3, and V3 are 
given in Appendix G. 



STATEMENT NUMBER ENTRY; A statement number 
entry is constructed for each statement 
number encountered in the source state- 
ments. The format of an entry in the 
statement number chains is illustrated in 
Figure 68. 



r t t 1 

| chain | usage | packed statement number | 

j. 1 x -J 

| 2 bytes | 1 byte| 3 bytes j 

l x x j 

Figure 68. Format of Statement Number 
Information in the Overflow 
Table 



The fields of a statement number 
contain the following information: 



entry 



The first field contains the displace- 
ment (relative to the beginning of the 
overflow table) of the next element in 
the chain. 



• The third field contains the actual 
statement number (as it appeared in the 
source statement) in packed form. 



r t 

Usage 
Field 
Bit 



Function of the Field 



Indicates if the statement number 
is defined 



Indicates if the statement number 
is referenced 



Indicates if the statement number 
represents the end of a DO loop 



Indicates if the statement number 
represents a specification state- 
ment 



-+- 



Indicates if tne statement number 
represents a FORMAT statement 



Indicates if the statement number 
indicates DO nesting errors 



Not used 



Not used 



Figure 69. Statement Number Entry Usage 
Field Bit Functions 
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SEGMAL 



Phase 7 Use 



SEGMAL, constructed by Phase 5, contains 
the beginning and ending address of each 
segment of main storage assigned to the 
dictionary and overflow table by Phase 5. 
This main storage is assigned to the com- 
piler as a result of the GETMAIN macro- 
instruction issued by the compiler during 
Phase 5. SEGMAL resides at the beginning 
of the lowest segment assigned to the 
dictionary and overflow table. 



Phase 7 uses SEGMAL to load: (1) the 
dictionary index and the reserved word 
portion of the dictionary into the diction- 
ary, and (2) the overflow index into the 
overflow table. In addition. Phase 7 uses 
SEGMAL to reinitialize the above-mentioned 
fields in the communication area. 



Phases 10D, 10E, and 14 Use 



Phase 1 Use 



Phase 1, between compilations in a batch 
SPACE run, frees the overflow table and 
SEGMAL via SEGMAL. For all compilations, 
before returning control to the calling 
program, Phase 1 uses SEGMAL to free any 
remaining segments in the dictionary and 
overflow table. 



Phases 10D and 10E use SEGMAL when new 
segments of the dictionary and overflow 
table are required. For SPACE 
compilations, Phase 14 uses SFGMAL to free 
the main storage areas allocated to the 
dictionary. 



Format of SEGMAL 



Phase 5 Use 



When SEGMAL is constructed by Phase 5, 
the various segments are put into ascending 
order; that is, the segment entries of main 
storage are sorted. Contiguous segments 
are then combined into a single segment. 

The communication area contains fields 
that are used to indicate which segment is 
currently being used for the overflow table 
and which is currently being used for the 
dictionary. 



Figure 70 illustrates the format of 
SEGMAL for N segments, where each segment 
is entered in ascending sequence by 
address. The entry for each segment con- 
sists of the beginning address of the 
segment and the ending address of the 
segment plus 1. (The storage location 
containing the ending address of segment N 
is adjacent to the storage location con- 
taining the starting address of the over- 
flow index. The starting address of the 
overflow index is an entry in the communi- 
cation area. ) 

Note: The ending address of segment N 
minus the beginning address of segment 1 
must be less than or equal to 65,536. 



r T T T 7 / T T 1 

| beginning | ending ad- | beginning | ending/ / | beginning | ending ad- | 
I address of | dress of j address of j addr / - -/ j address of j dress of j 
j segment 1 j segment 1 j segment 2 j seg / / j segment N j segment N j 
j. x x x -V h x x -l 

j 4 bytes | 4 bytes | 4 bytes | / / | 4 bytes | 4 bytes | 

,. x + x — y / x x ^ 

j entry for segment 1 | / / | entry for segment N | 
l x f L x J 

Figure 70. Format of SEGMAL 
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PATCH TABLE 



The patch table (100 bytes) is a part of 
the interface module. It is used only if 
the patch facility has been enabled and if 
patch records precede the source statements 
of the FORTRAN source module being com- 
piled. The patch table (constructed by 



Phase 5) contains a converted form (for 
internal use) of the information contained 
in the patch records. When the patch table 
is full, any further patch records are 
ignored and are not placed onto the SYS- 
PRINT data set. 

Figure 71 illustrates the format of the 
patch table. 



t 1 

2 bytes 



Identifier for first module to be modified 



Relative address of first patch for this module 



2 bytes 



Length (in bytes) of first patch for this module 



2 bytes 



First patch for this module 



Variable 



Relative address of last patch for this module 



2 bytes 



Length (in bytes) of last patch for this module 



2 bytes 



Last patch for this module 



Variable 



00000001 (Indicates last patch for this module) 



4 bytes 



Identifier for last module to be modified 



2 bytes 



Relative address of first patch for this module 



2 bytes 



Length (in bytes) of first patch for this module 



2 bytes 



First patch for this module 



Variable 



Relative address of last patch for this module 



2 bytes 



Length (in bytes) of last patch for this module 



2 bytes 



Last patch for this module 



Variable 



00000001 (Indicates last patch for this module) 



4 bytes 



ZZ (Indicates last module to be patched) 

I 

Figure 71. Format of the Patch Table 



2 bytes 
x J 
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BLOCKING TABLE 



The blocking 
Phase 5 only for 
5 constructs a 
each of the data 
compiler data s 
contains the 
deblocking compil 
compiler output. 



table is constructed by 
PRFRM compilations. Phase 
blocking table entry for 
control blocks for the 
ets. The blocking table 
information required for 
er input and for blocking 



Each blocking table entry is 24 bytes in 
length. Figure 72 illustrates the format 
of a blocking table entry. 



Logical record length x 
(2 bytes) 



Blocking factor 



(2 bytes) 



Address of buffer 2 (next) 
(4 bytes) 



Address of buffer 1 (current) 
(4 bytes) 



Address of next logical record 
within the current buffer 
(4 bytes) 



Address to or from which the next 
record is to be moved 

(4 bytes) 



Number of logical records in current 
buffer that remain to be processed 
(2 bytes) 



Indicates if priming is required (input 
data sets only) 

(1 byte) 



Indicates the I/O activity for this 
data set 

(1 byte) 



^O for SYSIN, SYSLIN, SYSUT2, and 
SYSPUNCH; 121 for SYSPRINT 

L 

Figure 72. Blocking Table Entry Format 



transferred via an XCTL macro- instruction, 
and (2) a 36-byte field for each of the 
above names. The BLDL routine completes 
the skeleton BLDL table by placing 
information into these 36-byte fields. 
This information is obtained from the data 
set directory of the partitioned data set 
containing the FORTRAN IV (E) compiler. 
This information (such as the physical 
location of each compiler component in the 
partitioned data set) is used for transfer- 
ring control from one component of the 
compiler to the next for PRFRM compila- 
tions. 

The BLDL table allows more efficient 
phase-to- phase transition, through the use 
of the DE parameter in the XCTL macro- 
instruction, than is possible for a SPACE 
compilation in which the EPLOC parameter 
must be used. For a description of the 
XCTL macro-instruction and the DE and EPLOC 
parameters, refer to the publication IBM 
System/360 Operating System; Control 
Program Services . 

Each entry in the BLDL table is 44 bytes 
in length. Figure 73 illustrates the for- 
mat of the BLDL table. 

NOTE: Although entries for the interludes 
are included in the BLDL table, the inter- 
ludes are never executed for a PRFRM compi- 
lation. When an interlude is specified in 
the linkage to the end-of-phase routine 
(PNEXT) in the performance module, the 
phase in the BLDL table that follows the 
specified interlude is automatically trans- 
ferred to by modifying the XCTL macro- 
instruction to point to the directory entry 
for that phase. 



RESET TABLE ( RESET ABL) 



The reset table is a 39-byte index table 
that is used by the PNEXT routine in the 
performance module to determine which, if 
any, of the record counts for the chained 
buffer data sets (SYSUTl and SYSUT2) must 
be reset. The record count of the data set 
that is to be used for output by the next 
phase is always reset. 



BLDL TABLE 



The BLDL table is constructed by Phase 5 
only for PRFRM compilations. It is built 
using a BLDL macro- instruction. Phase 5 
supplies, as a parameter of the BLDL macro- 
instruction, the address of a skeleton BLDL 
table. The skeleton BLDL table contains: 
(1) the names (8 bytes per name) of the 
compiler components to which control may be 



The fifth character in the symbolic name 
of the phase to be executed next is used to 
reference the appropriate entry in the 
table. If the value of that entry is zero, 
no action is taken. If the value is two, 
the record count in the blocking table 
entry for SYSUTl is reset. If the value is 
eight, the record count in the blocking 
table entry for SYSUT2 is reset. Resetting 
the record count is necessary in oraer to 
determine whether actual READS are required 
for the data set when it is used as input 
by a subsequent phase. 
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Compiler 
component 
(8 bytes) 



IEJFAABO 
(Phase 1) 
subsequent 
entries 



Directory information for 
compiler component 
(36 bytes) 
+ 

Directory information for 
Phase 1 (subsequent 
entries) 



IEJFCAAO 
(Phase 5) 



Directory information 
Phase 5 



for 
for 
for 



IEJFEAAO 
(Phase 7) 

I 

IEJFFAAO 
(Phase 8) 



Directory information 
Phase 7 



Directory information 
Phase 8 



IEJFGAAO 
(Phase 10D) 



Directory information 
Phase 10D 



for 



IEJFJAAO 
(Phase 10E) 



Directory information 
Phase 10E 



for 
for 
for 
for 
for 
for 
for 
for 
for 
for 



IEJFJGAO 
(Interlude 10E) 



Directory information 
Interlude 10E 



IEJFLAAO 
(Phase 12) 



Directory information 
Phase 12 



IEJFNAAO 
(Phase 14) 



Directory information 
Phase 1H 



IEJFNGAO 
( Interlude 



1H) 



IEJFPAAO 
(Phase 15) 



Directory information 
Interlude 14 
+ — 



Directory information 
Phase 15 



IEJFPGAO 
(Interlude 
| 

IEJFRAAO 
(Phase 20) 



15) 



Directory information 
Interlude 15 



Directory information 
Phase 20 



IEJFVAAO 
(Phase 25) 



Directory information 
Phase 25 



IEJFXAAO 
(Phase 30) 



Directory information 
Phase 30 



Figure 73. BLDL Table Format 
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APPENDIX I: TABLES USED BY PHASE LOAD MODULES 



During a compilation, the compiler uses 
the following tables: 



• Allocation table. 

• Routine displacement tables, 

• EQUIVALENCE table. 

• Forcing value table. 

• Operations table. 

• Subscript table. 

• Index mapping table. 

• Epilog table. 

• Message length table- 

• Message address table. 

• Message text table. 



Some tables are actual segments of the 
phase load modules; others are created 
during the compilation. Each table is used 
only by the phase that contains it (as a 
part of the phase load module) or creates 
it. The following discussions describe the 
use and format of each table. 



ALLOCATION TABLE 



The allocation table is a part of the 
Phase 5 load module. It is used to 
allocate the amount of main storage 
obtained among buffer areas and resident 
tables. Table 27 illustrates the format of 
the allocation table. 



ROUTINE DISPLACEMENT TABLES 



The routine displacement tables for re- 
served word processing routines are parts 
of the Phase 10D and Phase 10E load 
modules. Reserved words are those that 
indicate a specific FORTRAN statement. The 
Phase 10D and Phase 10E routine displace- 
ment tables are identical in structure and 
in purpose (locating the processing routine 
for a given reserved word) . The Phase 10D 
table aids in the location of reserved word 
routines for declarative statements; the 
Phase 10E table aids in the location of 
reserved word routines for executable 
statements . 

Each reserved word causes an entry to be 
made in the dictionary by Phase 7 (refer to 
Appendix H) . The address field of these 
entries contains a displacement, used as an 
indexing value, relative to the start of 
the appropriate routine displacement table. 



Table 27. Allocation Table 



SIZE 



Average number of 
source statements 
that can be compiled 



Dictionary and 
Overflow 
Table Size 
(in bytes) 



"T 

I PRFRM 



Internal Text Buffer 
Size (in bytes) 

t 

SPACE I PRFRM 



H 



SPACE I 1 PRFRM 
I 

k + 

15K | 19K 

44K j 48K 

86K | 90K 

200K I 204K 



SPACE 



170 
2500 
6500 
6500 



PRFRM 

| 170 

| 1980 

| 6500 

| 6500 



SPACE 



I/O Buffers | I/O Buffersj 



Non-I/O 
Buffers 



+ + + . 

2216 | 2216 
25512 |20328 
65536 | 65536 
65536 J65536 
JL 



4x(104) | 
4x(1704) j 
4x(1704) | 
4x<1704) j 
x. 



4x(96) | 

4x(1696) j 5184 

4x(1696) | 8104 

4x(1696) | 119720 

JL 



^■If blocked I/O is specified, the value of the expression 2*(BLKSIZE) must be added, 
for each data set that contains blocked records, to the number shown under the PRFRM 
option. 
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This index is used to obtain the actual 
displacement, relative to a base register, 
of a specific reserved word routine located 
within the Phase 10D or Phase 10E load 
module. The effective address of the 
desired reserved word routine is obtained, 
by Phase 10D or Phase 10E, by adding this 
displacement to the value in the base 
register. 



Figures 74 and 75 illustrate the format 
of the routine displacement tables. 



r 1 

Displacement from base register value of 
DEFINE FILE reserved word routine 



Displacement from base register value of 
REAL reserved word routine 



Displacement from base register value of 
COMMON reserved word routine 



Displacement from base register value of 
FORMAT reserved word routine 



Displacement from base register value of 
DOUBLE reserved word routine 



Displacement from base register value of 
INTGER reserved word routine 



Displacement from base register value of 
EXTERN reserved word routine 



Displacement from base register value of 
FONCT reserved word routine 



Displacement from base register value of 
DIM reserved word routine 



Displacement from base register value of 
SUBRUT reserved word routine 



h 



Displacement from base register value of 
EQUIV reserved word routine 



2 bytes 
i j 

Figure 74. Phase 10D Routine Displacement 
Table Format 



r 1 

Displacement from base register value of 
FIND reserved word routine 



Displacement from base register value of 
DO reserved word routine 



Displacement from base register value of 
GO reserved word routine 



Displacement from base register value of 
FORMAT reserved word routine 



Displacement from base register value of 
IF reserved word routine 



Displacement from base register value of 
END reserved word routine 



Displacement from base register value of 
CALL reserved word routine 



Displacement from base register value of 
GOTO reserved word routine 



Displacement from base register value of 
READ reserved word routine 



Displacement from base register value of 
STOP reserved word routine 



Displacement from base register value of 
PAUSE reserved word routine 



Displacement from base register value of 
WRITE reserved word routine 
I— 



Displacement from base register value of 
RETURN reserved word routine 



Displacement from base register value of 
REWIND reserved word routine 



Displacement from base register value of 
ENDFIL reserved word routine 



Displacement from base register value of 
CONT reserved word routine 



Displacement from base register value of 
BKSP reserved word routine 



H h 



H 



| 2 bytes | 

L J 

Figure 75. Phase 10E Routine Displacement 
Table Format 
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Figure 76 illustrates how the DO re- 
served word routine is located in Phase 
10E. 



1 



L — -h 
r i 



L — -H 



Dictionary entry for GO 



Phase 10E Routine Displacement 
Table 
1 

Displacement for FIND | 

reserved word routine j 

., 

Displacement for DO | 

reserved word routine 



Displacement for BKSP 
reserved word routine 



DO reserved word 
processing routine 



Figure 76. Locating the DO Reserved Word 
Routine 



Each field in an entry is two bytes in 
length. The first field contains a pointer 
to the entry for the variable or array in 
the dictionary. The second field contains 
a pointer to the dictionary entry for the 
root to which the variable or array is 
equated. (If the variable or array is the 
root of the EQUIVALENCE group, the first 
two fields contain the same pointer.) The 
third field contains the displacement or 
address assigned to the variable or array 
in COMMON. (The addresses for variables 
and arrays are assigned before this table 
is constructed.) The fourth field is the 
size, in bytes, of the EQUIVALENCE group or 
class. 



The maximum number of entries in the 
EQUIVALENCE table is the larger of: 



• 100, or 

• The largest unused segment of the dic- 
tionary and overflow table divided by 
eight (if this segment exceeds 800 
bytes) . 

For example, if the compiler allocates 
5500 contiguous bytes to the dictionary ana 
the overflow table, and 3100 bytes are 
used, then the maximum number of entries in 
the EQUIVALENCE table is: 



EQUIVALENCE TABLE 



(5500 - 3100)78 = 2400/8 = 300 



The EQUIVALENCE table is constructed by 
Phase 12 for use by the Phase 12 storage 
allocation routines, which assign addresses 
to equated variables. This table is a 
serial list in which each member follows 
the preceding one. 

The format of a typical entry in the 
EQUIVALENCE table is as follows: 



r t t t 1 

I p (variable) I p (root) I displacement | size | 

| or p (array) j |or address inj j 

j | | COMMON j | 

| 2 bytes | 2 bytes | 2 bytes | 2 bytes | 
l x x x J 



FORCING VALUE TABLE 



The forcing value table is a part of the 
Phase 15 load module. The forcing value 
table is used by Phase 15 as an aid in the 
reordering of intermediate text entries in 
arithmetic expressions. This table defines 
the relative position of each operator in 
the hierarchy of operators. 

Each entry in the forcing value table is 
five bytes in length. The forcing value 
table is illustrated in Figure 77. 



140 



r t 

Adjective 
Code 



I- 

n 



|. X 



+- 



h 

/ 

I- 



** 

I- 

F( 

unary - 

I- 

end mark 



unary + 



SF 
Forcing 

ARITH 
Forcing 



CALL 
Forcing 

i- 

IF 
Forcing 



Left j Address of 
Forcing j Associated 
Value | Routine 



64 



a(LFTPRN) 



00 



a(RTPRN) 



70 



a (EQUALS) 



49 | a (COMMA) 

80 j never 

| forced out 



09 | a (ADD) 
09 I a (ADD) 



05 | a (MULT) 
05 I a (MULT) 



04 ja(EXPON) 
64 |a(FUNC) 

05 |a(UMINUS) 
-+- 



00 I never 

| forced out 



05 ja(UPLUS) 



72 ja(END) 

I 
72 | a (END) 



72 | a (CALL) 

I 
72 ja(END) 



Right 

Forcing 

Value 



01 
69 



70 
48 
01 






09 
09 






05 
05 






03 
01 
01 
80 









01 



70 



70 



70 



h + x + - 

j 1 byte j 1 byte | 2 bytes | 
l x x X— 

Figure 77. Forcing Value Table 



OPERATIONS TABLE 



70 
1 byte 



The operations table can contain no more 
than 50 entries. Entries are four bytes in 
length and are obtained by a pointer to the 
last entry in the table for the specific 
statement under consideration. The format 
of a typical entry in the operations table 
is shown in Figure 78. 



r t t 1 

| ad j code | mode/type | pointer | 
,. x x 1 

| 1 byte j 1 byte j 2 bytes | 
l x x J 

Figure 78. Operations Table Entry Format 



SUBSCRIPT TABLE 



The subscript table is a temporary stor- 
age area (part of the Phase 15 load module) 
used for subscript text encountered during 
the reordering of intermediate text words 
by Phase 15. This table functions as a 
"pushdown table" (that is, a table in which 
the top entry is the most recently entered 
item) for storing subscript intermediate 
text words that refer to the operation in 
question. 

The subscript table can contain no more 
than 38 entries. Entries are eight bytes 
in length and are obtained by a pointer to 
the top entry in the table for the specific 
statement under consideration. The format 
of a typical entry in the subscript table 
is shown in Figure 79. 



r t t 1 

j subscript | not used | | 

| adjective j by j offset | 
j code | Phase 15 J j 

y x x H 

| p (subscript) | p (dimension) | 

(. T x ^ 

j 1 byte | 1 byte | 2 bytes j 
l x x J 

Figure 79. Subscript Table Entry Format 



The operations table is a temporary 
storage area (part of the Phase 15 load 
module) used during the reordering of oper- 
ations within statements that can contain 
arithmetic expressions. This table func- 
tions as a "pushdown table" (that is, a 
table in which the top entry is the most 
recently entered item) for storing inter- 
mediate text words that refer to the opera- 
tion in question. An exception is made for 
subscript text, which is stored in the 
subscript table. 



The subscript adjective code indicates 
to other phases of the compiler that sub- 
script calculation is necessary. The off- 
set is an index used to find the correct 
element in an array associated with a 
particular subscript expression. The sec- 
ond word of an entry in the subscript table 
contains two pointers to information in the 
overflow table. The first points to the 
subscript information for the subscripted 
variable; the second points to the dimen- 
sion information for the array indicated by 
the subscripted variable. 
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INDEX MAPPING TABLE 



The index mapping table (part of the 
Phase 20 load module) is used to aid the 
implementation of subscript optimization. 
This table maintains a record of all infor- 
mation pertinent to a subscript expression. 
Because the computation of any unique sub- 
script expression is placed in a register, 
the number of entries in the table depends 
on the number of registers available for 
this purpose. The initial register 
assigned to a subscript expression is det- 
ermined during the initialization process 
for Phase 20. Each entry in the index 
mapping table is eight bytes in length. 
The format of a typical entry in the index 
mapping table is shown in Figure 80. 



Each entry in the epilog table is four 
bytes in length. The format of a typical 
entry in the epilog table is shown in 
Figure 81. 



r t t 1 

|L \s | address | 
|. + 1 H 

|1 byte |1 byte | 2 bytes j 
L x J. j 

Figure 81. Epilog Table Entry Format 



L is the field length of the variable in 
the subprogram, S is the relative position 
of the variable in the parameter list of 
the calling program, and address is the 
address of the variable in the subprogram. 



r t t t 1 

| | number | | | 

| regis- | of | status j offset | 
| ter j dimen- 1 j j 

| number j s ions j j j 

,. ± j. 1 .j 

| p (subscript) | p (dimension) | 
j. T 1 ., 

| 1 byte | 1 byte | 2 bytes | 

L JL J. J 

Figure 80. Index Mapping Table Entry For- 
mat 



The register number field contains the 
number of the register assigned to the 
subscript expression. The dimension number 
field contains the number 1, 2, or 3, 
depending on the number of dimensions. The 
status field indicates whether the register 
referenced by this entry is: (1) unas- 
signed, (2) assigned to a normal subscript 
expression for indexing computation, or (3) 
assigned to the address of a dummy vari- 
able. The offset field contains the offset 
index used to obtain the correct element of 
the array associated with a particular 
subscript expression. The last two fields 
contain pointers to information in the 
overflow table. 



MESSAGE LENGTH TABLE 



The message length table is loaded into 
main storage as a part of the Phase 30 load 
module. It contains tne lengths of all the 
messages capable of being generated by the 
compiler. The length of any message is 
obtained by using the number corresponding 
to that message as a displacement from the 
start of the message length table. 



Figure 82 illustrates the format of 
message length table. 



the 



r i 

| Length of first message | 

|. .j 

| Length of second message J 
|. .j 

I • I 

I • I 

I • I 

y ., 

| Length of last message | 

,. ., 

j 1 byte j 

L J 

Figure 82. Message Length Table Format 



EPILOG TABLE 



The epilog table is created by Phase 25 
when the FUNCTION or SUBROUTINE adjective 
code is encountered. An entry is made in 
the epilog table for each variable used as 
a parameter in the calling program. The 
instructions generated during Phase 25 for 
the RETURN entry in the intermediate text 
reference the epilog table to return the 
value of variables to the calling program. 



MESSAGE ADDRESS TABLE 



The message address table is loaded into 
main storage as a part of the Phase 30 load 
module. It contains the displacements from 
the start of the message text table of all 
the messages capable of being generated by 
the compiler. The displacement of any 
message is obtained by using the number 
corresponding to the message multiplied by 
two as a displacement from the start of the 
message address table. 
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Figure 83 illustrates the format of the 
message address table. 



j Displacement of text for first message 
| from start of the message text table 



| Displacement of text for second message 

jfrom start of the message text table 

|. 



j Displacement of text for last message 
jfrom start of the message text table 



Figure 83. 



2 bytes 
Message Address Table Format 



MESSAGE TEXT TABLE 



The message text table is loaded into 
main storage as a part of the Phase 30 load 



module. It contains all the messages capa- 
ble of being generated by the compiler. 
Each message is obtained by using the 
displacements contained in the message 
address table. 



Figure 84 illustrates the format of the 
message text table. 



Message 
message 


text corresponding to 
number 


first 


Message 
message 


text corresponding to 
number 


second 


• 


Message 
message 


text corresponding to 
number 


last 




Variable length 





Figure 84. Message Text Table Format 
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APPENDIX J: TABLES USED BY THE OBJECT MODULE 



The following tables are used by the 
object module to execute the instructions 
generated by the compiler: 

• Branch list table for referenced state- 
ment numbers. 

• Branch list table for SF expansions and 
DO statements. 

• Argument list table for subprogram and 
SF calls. 

• Base value table. 

The following discussions describe the 
use and format of each table. 



BRANCH LIST TABLE FOR SF EXPANSIONS AND DO 
STATEMENTS 



Phase 20 allocates storage for the 
branch list table for SF (statement 
function) expansions and DO statements. 
During Phase 25 processing, the relative 
addresses for the first executable instruc- 
tions in the SF expansions and DO loops are 
inserted into locations relative to the 
start of the branch table. The locations 
for the SF expansions were determined by 
Phase 14; the locations for the DO loops 
are determined by Phase 25. The table is 
used, at object time, either by the 
instructions generated to reference SF 
expansions or by the instructions generated 
to control the iteration of DO loops . 



BRANCH LIST TABLE FOR REFERENCED STATEMENT 
NUMBERS 



Phase 12 allocates storage for the 
branch list table for referenced statement 
numbers and assigns a relative position 
(relative to the start of the branch table) 
to each executable statement that is ref- 
erenced by other statements. Phase 25 
inserts the relative addresses, for these 
statements, into the positions dictated by 
Phase 12. The table is used, at object- 
time, by the instructions generated to 
branch to executable statements. 

Each entry in the table is the address 
of a referenced statement number. The 
format of the branch list table for 
referenced statement numbers is illustrated 
in Figure 85. 



address of first referenced statement 
number 



address of second referenced statement 
number 



address of last referenced statement num- 
ber 



4 bytes 



Each entry in the table is either the 
address of the first instruction in an SF 
expansion or the address of the second 
instruction in a DO loop. (The first 
instruction of the DO loop initializes the 
DO counter. ) The format and organization 
of the branch list table for SF expansions 
and DO statements is illustrated in Figure 
86. 



j address 
jsion 1 


of 


first instruction in SF expan- | 


j address 
jsion 2 


of 


first instruction in SF expan- j 


1 • 1 


j address 
jsion N 


of 


first instruction in SF expan- j 


j address 
|1 


of 


second instruction in DO loopj 


j address 
|2 


of 


second instruction in DO loopj 


1 • 1 


j address 
|M 


of 


second instruction in DO loop| 


| 4 bytes j 



Figure 85. Format of Branch List Table for 
Referenced Statement Numbers 



Figure 86. Format of Branch List Table for 
SF Expansions and DO Loops 
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All SF definitions must appear prior to 
the executable statements (this includes DO 
statements) in a source module. Therefore, 
Phase 25 encounters all the SF adjective 
codes prior to the first DO statement 
adjective code. This accounts for the 
placement of all SF expansion addresses 
into the branch table before the first DO 
loop address. 



ARGUMENT LIST TABLE FOR SUBPROGRAM AND SF 
CALLS 



Phase 20 allocates storage for the argu- 
ment list table for the arguments of sub- 
program and SF calls. During Phase 20 
processing, the relative addresses of the 
above arguments are inserted into the argu- 
ment list table. The starting address of 
the first argument of each argument list is 
passed as part of the intermediate text to 
Phase 25 (the total number of SFs is passed 
in the communication area) . 



Each entry in the argument list table is 
either the address of an argument used in a 
subprogram or the address of an argument 
used in an SF. Entries are made in the 
table as Phase 20 encounters each subpro- 
gram or SF reference. The format and 
organization of the argument list table is 
illustrated in Figure 87. 



BASE VALUE TABLE 



The base value table is generated by the 
various phases of the compiler as base 
registers are required by the object cod- 
ing. The table is assembled in its final 
form by Phase 25. The compiler-generated 
instructions that load base registers, at 
object time, use the base value table in 
order to obtain the proper base register 
values . 



r 1 

first argument of first subprogram or SF 
reference encountered 



last argument of first subprogram or SF 
reference encountered 



first argument of second subprogram or SF 
reference encountered 



last argument of second subprogram or SF 
reference encountered 



first argument of last subprogram or SF 
reference encountered 



last argument of last subprogram or SF 
reference encountered 



h 



H 



| 4 bytes | 

i j 

Figure 87. Format of Argument List Table 
for Subprogram and SF Calls 



r 1 

value placed in the first base register 
used to obtain data in COMMON 



value placed in the last base register 
used to obtain data in COMMON 



value placed in the first base register 
used to obtain data in the object module 



value placed in the last base register 
used to obtain data in the object module 



Figure 88 illustrates the format and 
organization of the base value table. 



j 4 bytes | 

L J 

Figure 88. Format of Base Value Table 
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APPENDIX K: DIAGNOSTIC MESSAGES AND STATEMENT/EXPRESSION PROCESSING 



This appendix contains the names of the 
phases and the routines within the phases 
that: (1) generate diagnostic messages, and 
(2) process the various FORTRAN statements 
and expressions. 



DIAGNOSTIC MESSAGES 



Two types of diagnostic messages are 
generated by the FORTRAN compiler - infor- 
mative messages and error/warning messages. 
The messages produced by the compiler are 
explained in the IBM System/360 Operating 
System; FORTRAN IV (E) Programmer's Guide . 



Informative Messages 

Four informative messages are generated 
by the compiler to inform the programmer or 
operator of the status of the compilation. 
The messages and the phases and subroutines 
in which they are generated are illustrated 
in Table 28. 

Table 28. Informative Messages 

r t t 1 

| Message/ number | Phase |Subrtn. | 

,. + + ^ 

JIEJ001I j 5 JMESSGOUT j 
,. + + .J 

| LEVEL: rmthyr j j j 

| IBM OS/ 360 BASIC FORTRAN j j j 

| IV (E) COMPILATION j j | 

| DATE: yy.ddd j 7 |EJECTPRT | 

|. + + i 

j SIZE OF COMMON xxxxxx | 30 |ENDCRD | 

| PROGRAM yyyyyy I | | 

h + - + 1 

| END OF COMPILATION zzzzzz| 30 JEOJOB j 
L X ± J 



Error/Warning Messages 



Each error/warning message produced by 
the compiler is identified by an associated 
number. Table 29 relates a message number 
with the phase (s) and subroutine (s) in 
which the corresponding message is generat- 
ed. 



Table 29. Error/Warning Messages 



j Message 
I Number 



IEJ002I 



IEJ003I 



IEJ004I 



IEJ005I 



IEJ006I 



IEJ007I 



IEJ008I 



IEJ029I 



IEJ030I 



IEJ031I 



IEJ032I 



IEJ033I 



■+" 



IEJ03UI 



IEJ035I 



IEJ036I 



IEJ037I 



IEJ038I 



IEJ039I 



IEJ041I 



IEJ043I 



IEJ0U3I 



IEJ044I 



■+ 



IEJ045I 



IEJ046I 



IEJ047I 



IEJ048I 



IEJ049I 



Phase 



10D 



10D 



12 



10D,10E 



10D,10E 



10D 



10D 



10E 



10D,10E 



10D 



10D,10E 



10D,10E 



1GD,10E 



12 



10D f 10E 



10D,10E 



10D, 10E 



10D,10E 



10D 



10D 



Subroutine or Routine 



MESSGOUT 



MESSGOUT 



MESSGOUT 



MESSGOUT 



MESSGOUT 



MESSGOUT 



MESSGOUT 



DIMSUB 



COMMON, EQUIVP 



EQUIVP 



LITCON 



GETWD 



FUNCT, SUBRUT 



FUNCT, SUBRUT 



ARITH 



CLASS, ARITH, ASF, IF 



INTGER/REAL/DOUBLE , 
EXTERN, COMMON, EQUIV, 
DIM 



SYMTLU 



ASF, EXTERN, DIM 



INTGER/REAL/DOUBLE, GO 



ALOC 



LITCON 



LITCON 



LITCON 



CLASS, DIM 



DIMSUB 



DIM, DIM90 



(Continued) 
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Table 29. Error/Warning Messages 

r t t n 

Message | Phase | Subroutine or Routine 
Number | | 



IEJ050IJ10D 



IEJ051IJ10D 



IEJ051I|14 



IEJ052IJ10D 



IEJ053IJ10D 



IEJ054IJ10E 



IEJ055IJ10D 



IEJ056II10E 



IEJ057IJ10E 



h 
j] 

h 

j] 
h 

h 

h 
j] 

h 
j] 

h 
j] 

h 
j: 

h 

h 

j] 

H 
h 

h 
h 

IEJ066I|10E 
IEJ067I|10D 



( EQUIV 



j EQUIV, DIM 



j FCOMACHK 



JSUBS, EQUIV 



SOBS 



I ASF 



JFUNC, SOBRUT 



| GO 



I READ/WRITE 



IEJ058IJ10E 



j READ/WRITE 



IEJ060IJ10D 



I EQUIV 



IEJ061I|10D,10E JEOSR 



IEJ063IJ10E 



j EQUIV 



IEJ064I|10D,10E, |LABTLU # SYMTLU, 



IEJ064IJ30 



I TWNFIV 



IEJ065ljlOD,10E j CLASS, LABLU, PAKNUM 



| DO 

I DEFINE 






IEJ068I |10D f 10E |LITCON 



IEJ069I|10E 



I ASF 



IEJ070IJ10D 



FUNCT, SUBRUT 



IEJ071I|10E 



JCALL 



IEJ072IJ10E 



ARITH 



IEJ073I|10D,10E |PUTX 



IEJ074IJ10D 



COMMON 



IEJ075I|14 



| FORMAT, CKLM 



IEJ076IJ14 



| READ/READWR , FORMAT 



+ 

IEJ077I|10D,10E 



| ASF, READ/WRITE, EOSR, 
|DO, SUBS, EQUIV, FUNCT, 
| SUBRUT, DIMSUB, DIM, 
| SKPBLK 



IEJ077I|14 | READ/READWR, DO, FILLEG, 

j j SKPBLK 
X X 



r t 

Message I Phase 
Number | 

IEJ078I|14 
h 



( Continued) 



IEJ082I|10D,10E JLITCON 



IEJ082I|1«* 



h 

h 

h 

IEJ083IJ14 
j. + 

IEJ084I|10D,10E 



j Subroutine or Routine 
I 

I CKENDO 



IEJ079IJ10E 



I GO 



IEJ079IJ14 



READ/READWR, DO 



IEJ080I|10E 



I GO 



IEJ080I|14 



j READ/READWR 



IEJ081I|10D,10E j ARITH, EQUIV 



IEJ081I|14 j READ/READWR, FMDCON, 

j JFMECON, FMFCON, FMTINT, 
| JFMACON, FORMAT 



JNOFDCT, INTCON 



IEJ083I|10D,10E JCSORN, INTCON 



| INTCON 
■+- 



| WARN/ERRET 



IEJ084I|14 



[ERROR, WARN 



IEJ084IJ15 



| ERROR, WARN 



IEJ085I|12 



jDPALOC, SALO 



IEJ085I|14 



PRESCN 



IEJ086IJ14 



j BLANK Z 



IEJ087IJ14 j FMDCON, FMECON, FMFCON, 
j FMTINT, FMACON, FSUBST 



I- +— 

IEJ088IJ14 



IEJ089I|1U 



| LPAREN 
4 



UNITCK 



IEJ090I|14 



FQUOTE 



IEJ091I|14 



JFMINUS, FPLUS 



IEJ092I|14 



| FCOMMA 



IEJ093IJ14 



READ/READWR 



IEJ094I|14 | FMDCON, FMECON, FMFCON, 
| I FMTINT, FMACON 



IEJ095IJ14 



IEJ096IJ14 



h 

h 

IEJ098I|14 
I X 



READ/READWR 



| READ/READWR 



IEJ097IJ14 



INSAV 



FQUOTE 



(Continued) 
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Table 29. Error/Warning Messages 



r~ t - 

| Mess age | Phase 
| Number | 
L _ 1 


T ~ ~ 

| Subroutine or Routine 
4. _ _ 


|IEJ099I|14 

U — 4- — 


T 
| FQUOTE 


r T 

|IEJ100I|14 

J. + 

|IEJ123I|15 

L X 


T 

|DO, READ/READWR 
_ + 

j MOPUP 
i_ 


|IEJ124I|15 

L J. 


| EQUALS 
4— 


r — T 

|IEJ125I|15 
L — 4- 


T 

|DO # BEGIO 

X 


r T 
JIEJ126IJ15 

L_ 1 


T 

|CKARG 
i 


|IEJ127I|12 

L i 


ICOMALO, ALOC 
i 


|IEJ127I|15 

L J. 


|PRESCN f UMINUS, UPLUS, 
1 FOSCAN 
4- - 


|IEJ128I|15 

L _ X 


T 

j LFTPRN 


|IEJ129I|15 

L X- 


|TYPE 
4- — 


r — T 

| IEJ130I|15 

L X _ _ 


T 

| COMMA 

i 


|IEJ131I|15 

|. x 

|IEJ132I|15 

L _ X _ 


| INLIN1 
_ + 

| LABEL 

4. _ _ _ 


|IEJ133I|15 

L _ _ J. 


T 

j EQUALS 
_j._ 


r T 

|IEJ135I|15 

L X_ 


— |— — — — 

| COMMA, TYPE 


|IEJ136I|15 

L_ _ i 


T 
j LAB 


|IEJ137I|15 

L — 4. — - 


T 

| COMMA, TYPE, RTPRN, 

j FOSCAN 

X _ 


r T 

|IEJ139I|15 

f + 

JIEJ140IJ15 

L _ i _ 


T 

| COMMA 
_ + 

| FOSCAN 
x _ _ 


|IEJ141I|15 

|. + 

|IEJm2I|15 
L — 4- 


| COMMA 
_X 

|DO, BEGIO 
X — 


r t 

|IEJ143I|15 

|. + 

|IEJ144I|15 

L _ i. _ 


T 

| EQUALS 
_| 

| ARTHIF 

X — — 


|IEJ145I|20 

L _ _ i 


T 

| PHEND 
_X - _ 


|IEJ1U7I|12 

L _ i 


T 

j EQUIVP 

X _ 


r t — 
|IEJ148I|12 

L X 


T 

| RENTER/ENTER, SWROOT 

X 



Message 
Number 



IEJ149I 



IEJ150I 



■+- 



IEJ159I 



■+■ 



IEJ160I 



IEJ160I 



IEJ161I 



IEJ162I 



IEJ163I 



+- 



IEJ164I 



4- 



IEJ16UI 



IEJ166I 



■+ 



IEJ166I 



IEJ167I 



IEJ168I 



IEJ169I 



IEJ169I 



-+ 



IEJ171I 



IEJ171I 



IEJ172I 



IEJ173I 



IEJ174I 



Phase 



(Continued) 



12 



12 



15 



14 



15 



12 



10D,10E 



10D,10E 



10E 



14 



10D,10E 



14 



■+ 



14 



10D.10E 



10D 



15 



-+ 



10D,10E 



14 



10E 



10E 



15 



Subroutine or Routine 



COMALO 



ALOC 



MOPUP 



INTCON 



COMMA 



EXTCOM 



CLASS 



LITCON 



CONT/RETURN 



FORMAT 



EOSR, DO, FUNCT,SUBRUT 



READ/READWR 



LI NECK 



EOSR 



DIMSUB 



COMMA 



EOSR 



RPAREN 



ASF 



ARITH 



EQUALS, LFTPRN, INARG, 
TYPE 



|IEJ175I|14 
L X 



| LABEL 
.X 



STATEMENT/EXPRESSION PROCESSING 



Table 30 indicates the routine/subrou- 
tine responsible for the processing of the 
statement/expression under consideration, 
and the phase in which it appears. 
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Table 30. Statement/Expression Processing 



r T T T T T T T 1 

| Statement/ | Phase | Phase | Phase (Phase | Phase | Phase | Phase | 
j Expression | 10D/10E | 12 | 14 | 15 | 20 | 25 j 30 | 
j. + x + + X— X + ) 

j Arithmetic Expres- | I I I I I II 

jsion or Statement j ARITH (E) j JPASSON j FOSCAN JARITH j RXGEN | | 

I I I I I I |FUNGEN/ | | 

| FUNCTION Call |ARITH (E)|LDCN |PASSON | FOSCAN j CALSEQ (EREXIT | | 

I I II | FOSCAN, | | | | 

| Subscripted | | j JMVSBXX/j j j | 

|Variable | SUBS (E)|SSCK JPASSON JMVSBRX JSUBVP JSAOP, AOP j j 

I. + + + + + + + ^ 

|SF Definition and | I I I I |ASFDEF, | | 
j Expansion |ASF (E) |LDCN |ASF | FOSCAN | ARITH |ASFEXP | | 

j. X + + + + + X i 

j Statement Number | i I I I I II 

(Definitions | CLASS (E) |ASSNBL| LABEL | LABEL j LABEL j LABEL | | 

I. + + + + + + + ^ 

|SF Call | ARITH (E)|LDCN JPASSON | FOSCAN | CALSEQ | ASFUSE | | 

| |BKSP/REWIND I I I I I II 

| BACKSPACE |END/ENDFIL (E) | |BSPREF |D02 |ESDRLD | RDWRT | | 

|. + + + + + + + -I 

| | III | CALSEQ, j FUNGEN/ | j 

JCALL I CALL (E) |LDCN JPASSON | FOSCAN | IFCALL j EREXIT | | 

J. + + + + + + + ^ 

j COMMON | COMMON (D) | COMAL |COMEQUIV| | | | j 

j. + + + + + + + ^ 

| Computed GOTO |GO (E) | |CGOTO | CGOTO | COGOTO | CGOTO | | 

|. + + + + + + + -J 

I JCONT I I I I I II 

j CONTINUE | RETURN (E) | | SKIP | SKIP | | j | 

I. + + + + + + + ^ 

| DEFINE FILE | DEFINE (D) | | PAS SON | DEFNFL | | | j 

| DIMENSION | DIM (D) | | III I I 

|. -J. + + + + + + ^ 

|DO |DO (E) | |DO |DO | DO |D01,ENDDO | | 

| |INTGER/ (D) | | III I I 

j DOUBLE PRECISION j READ/DOUBLE | DPALOC j III II 

| | BKSP/REWIND/ I I I I I II 

|END JEND/ENDFIL (E) j | END | MOPUP |PHEND | END | ENDCRD | 

| | BKSP/REWIND/ I I I I I II 

JENDFILE JEND/ENDFIL (E) | | BSPREF | DO 2 |ESDRLD j RDWRT | | 

|. + + + + + + + ^ 

JEQUIVALENCE JEQUIV (D) | EQUIVP JCOMEQUIVJ j j j | 

|. + + + + + + + ^ 

j EXTERNAL j EXTERN (D)|LDCN j j | j j j 

| | READ/WRITE/ I I I I I II 
j FIND | FIND (E) | |READ |D02 j | RDWRT j | 
h + + + + + + + i 

j FORMAT | FORMAT (D,E) | j FORMAT | j | j j 

j j FUNCT/SUBRUT I I I I I j | 

| FUNCTION j (D) |LDCN | SUBFUN | FHDR | j SUBRUT | j 

JGO j GO (E) | JENDOCK j GOTO j j TRGEN j j 

| IF | IF (E) | |ENDOCK | FOSCAN | IFCALL |ARITHI | | 

t JL X X X X X X J 

(Continued] 
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Table 30. Statement/Expression Processing (Continued) 



r T T T T T T T 1 

I Statement/ | Phase | Phase | Phase | Phase | Phase | Phase j Phase | 
(Expression | 10D/10E j 12 | 14 | 15 | 20 | 25 | 30 | 
|. + + + + + + + ^ 

I I I I I I I FUNGEN/ | | 

| In-line Functions |ARITH (E) |LDCN |PASSON| FOSCAN| CKOD | EREXIT j | 

j. + + + + + 1 + ^ 

j JINTGER/ I I I I I I I 

| INTEGER | REAL/DOUBLE <D)|SALO | | | | | | 

J. + + + + + + + ^ 

| PAUSE j STOP/PAUSE (E) j j PAUSE JD02 j | STOP/PAUSE j | 

S | III | READ, |RDWRT/ | | 

jREAD I READ/WRITE (E) j |READ |D02 | LIST jlOLIST j | 

i + + + + -i- + + ^ 

j JINTGER/ I I I I I I I 

| REAL | REAL/DOUBLE (D)|SALO j j j | j | | 

j. + + + + + + + ^ 

| |CONT I I I I I I I 

j RETURN | RETURN (E) | j RETURN | SKIP j | RETURN j j 

I. + + + + + + + ^ 

j j BKSP/REWIND/ I I I I I I I 

| REWIND JEND/ENDFIL (E) j |BSPREF|D02 |ESDRLD |RDWRT | | 

| STOP | STOP/PAUSE (E) | | STOP |D02 | | STOP/PAUSE | | 

| | FUNCT/SUBRUT I I I I I I I 

j SUBROUTINE | (D)|LDCN |SUBFUN|D02 | | SUBRUT j | 

I I I I I I |RDWRT/ | | 

IWRITE IREAD/WRITE (E) I IREADWRID02 I LIST I IOLIST I I 



150 



APPENDIX L: OBJECT-TIME LIBRARY SUBPROGRAMS 



This appendix describes the logic of 
some of the object-time library subprograms 
that may be referenced by the FORTRAN load 
module. Included at the end of this appen- 
dix are flowcharts that describe the logic 
of the subprograms. (E is the first char- 
acter in the chart identification for each 
flowchart associated with a library subpro- 
gram. ) 



ing sequence to the IHCIBERR subprogram. 
IHCIBERR processes object-time errors 
resulting from improperly coded source 
statements. 



Each object module, compiled from a 
FORTRAN source module, must be first proc- 
essed by the linkage editor prior to execu- 
tion on the IBM System/360. The linkage 
editor must combine certain FORTRAN library 
subprograms with the object module to form 
an executable load module. The library 
subprograms exist as separate load modules 
on the FORTRAN system library 
(SYS1.F0RTLIB) . Each library subprogram 
that is externally referenced by the object 
module is included in the load module by 
the linkage editor. Among the library 
subprograms that may be so referenced are: 

• IHCFCOME (Object- time I/O source state- 
ment processor) - entry name IBCOM#. 

• IHCFIOSH (Object-time sequential access 
I/O data management interface) - entry 
name FIOCS#. 

• IHCDIOSE (Object-time direct access I/O 
data management interface) - entry name 
DIOCS#. 

• IHCIBERR (Object- time source statement 
error processor) - entry name IBERR#. 

IHCFCOME receives I/O requests from the 
FORTRAN load module via compiler- generated 
calling sequences. IHCFCOME, in turn, sub- 
mits these requests to the appropriate data 
management interface (IHCFIOSH or 
IHCDIOSE) . 

IHCFIOSH receives sequential access 
input/ output requests from IHCFCOME and, in 
turn, submits those requests to the 
appropriate BSAM (basic sequential access 
method) routines for execution. 

IHCDIOSE receives direct access 
input/output requests from IHCFCOME and, in 
turn, submits those requests to the 
appropriate BDAM (basic direct access 
method) routines for execution. 

If the LOAD option is specified, and if 
source statement errors are detected during 
compilation, the compiler generates a call- 



IHCFCOME 



IHCFCOME performs object-time implemen- 
tation of the following FORTRAN source 
statements . 

• READ and WRITE (for sequential I/O). 

• READ, FIND, and WRITE (for direct 
access I/O) . 

• BACKSPACE, REWIND, and ENDFILE 
(sequential I/O device manipulation) . 

• STOP and PAUSE (write-to-operator) . 

In addition, IHCFCOME: (1) processes 
object-time errors detected by various FOR- 
TRAN library subprograms, (2) processes 
arithmetic-type program interruptions, and 
(3) terminates load module execution. 

All linkages from the load module to 
IHCFCOME are compiler generated. Each time 
one of the above-mentioned source state- 
ments is encountered during compilation, 
the appropriate calling sequence to 
IHCFCOME is generated and is included as 
part of the object module. At object-time, 
these calling sequences are executed, and 
control is passed to IHCFCOME to perform 
the specified operation. 



Note: IHCFCOME itself does not perform the 
actual reading from or writing onto data 
sets. It submits requests for such opera- 
tions to the appropriate I/O data manage- 
ment interface (IHCFIOSH or IHCDIOSE). The 
I/O interface, in turn, interprets and 
submits the requests to the appropriate 
access method (BSAM or BDAM) routines for 
execution. Figure 89 illustrates the rela- 
tionship between IHCFCOME and the I/O data 
management interfaces. 

Charts EO, El, and E2 illustrate the 
overall logic and the relationship among 
the routines of IHCFCOME. Table 36, the 
IHCFCOME routine directory, lists the rou- 
tines used in IHCFCOME and their functions. 
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Figure 89. Relationship Between IHCFCOME 
and I/O Data Management Inter- 
faces 



(READ, FIND, and WRITE). (The direct 
access FIND statement is treated as a READ 
statement without format and list.) 

The I/O device manipulation routines 
implement the BACKSPACE, REWIND, and END 
FILE source statements for sequential data 
sets. These statements are ignored for 
direct access data sets. 

The write-to-operator routines implement 
the STOP and PAUSE source statements. 

The utility routines: (1) process errors 
detected by FORTRAN library subprograms, 
(2) process arithmetic-type program inter- 
rupts, and (3) terminate load module execu- 
tion. 



Read/Write Routines 



For the implementation of both sequen- 
tial and direct access READ and WRITE 
statements, the read/write routines of 
IHCFCOME consist of the following three 
sections: 

• An opening section, which initializes 
data sets for reading and writing. 

• An I/O list section, which transfers 
data from an input buffer to the I/O 
list items or from the I/O list items 
to an output buffer. 

• A closing section, which terminates the 
I/O operation. 

Within the discussion of each section, a 
read/write operation is treated in one of 
two ways : 

• As a read/ write requiring a format. 

• As a read/write not requiring a format. 



OPERATION OF IHCFCOME ROUTINES 

The routines of IHCFCOME are divided 
into the following categories: 

• Read/write routines. 

• I/O device manipulation routines. 

• Write-to-operator routines. 

• Utility routines. 

The read/write routines implement both 
the sequential I/O statements (READ and 
WRITE) and the direct access I/O statements 



Note: In the following discussion, the 
term "read operation" implies both the 
sequential access READ statement and the 
direct access READ and FIND statements. 
The term "write operation" implies both the 
sequential access WRITE statement and the 
direct access WRITE statement. 



OPENING SECTION: The compiler generates a 
calling sequence to one cf four entry 
points in the opening section of IHCFCOME 
each time it encounters a READ or WRITE 
statement in the FORTRAN source module. 
These entry points correspond to the opera- 
tions of read or write, requiring or not 
requiring a format. 
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Read/Write Requiring a Format: If the 
operation is a read requiring a format, the 
opening section passes control to the 
appropriate I/O data management interface 
to initialize the unit number specified in 
the READ statement for reading. (The unit 
number is passed, as an argument, to the 
opening section via the calling sequence.) 
The I/O interface: (1) opens the data 
control block (via the OPEN 
macro-instruction) for the specified data 
set if it was not previously opened, and 
(2) reads a record (via the READ 
macro-instruction) containing data for the 
I/O list items into an I/O buffer that was 
obtained when the data control block was 
opened. The I/O interface then returns 
control to the opening section of IHCFCOME. 
The address of the buffer and the length of 
the record read are passed to IHCFCOME by 
the I/O interface. These values are saved 
for the I/O list section of IHCFCOME. The 
opening section then passes control to a 
portion of IHCFCOME that scans the FORMAT 
statement specified in the READ statement. 
(The address of the FORMAT statement is 
passed, as an argument, to the opening 
section via the calling sequence.) The 
first format code (either a control or 
conversion type) is then obtained. 



For control type codes (e.g., an H 
format code or a group count) , an I/O list 
item is not required. Control passes to 
the routine associated with the control 
code under consideration to perform the 
indicated operation. Control then returns 
to the scan portion, and the next format 
code is obtained. This process is repeated 
until either the end of the FORMAT state- 
ment or the first conversion code is 
encountered. 



For conversion type codes (e.g., an I 
format code) , an I/O list item is required. 
Upon the first encounter of a conversion 
code in the scan of the FORMAT statement, 
the opening section completes its process- 
ing of a read requiring a format and 
returns control to the next sequential 
instruction within the load module. 

The action taken by IHCFCOME when the 
various format codes are encountered is 
illustrated in Table 31. 



I/O interface then returns control to the 
opening section of IHCFCOME. The address 
of an I/O buffer that was obtained when the 
data control block was opened is saved for 
the I/O list section of IHCFCOME. Subse- 
quent opening section processing, starting 
with the scan of the FORMAT statement, is 
the same as that described for a read 
requiring a format. 



Read/Write Not Requiring a Format: If the 
operation is a read or write not requiring 
a format, the opening section processing 
except for the scan of the FORMAT statement 
is the same as that described for a read or 
write requiring a format. (For a read or 
write not requiring a format, there is no 
FORMAT statement.) 



I/O LIST SECTION: The compiler generates a 
calling sequence to one of four entry 
points in the I/O list section of IHCFCOME 
each time it encounters an I/O list item 
associated with the READ or WRITE statement 
under consideration. These entry points 
correspond to a variable or an array list 
item for a read and write, requiring or not 
requiring a format. The I/O list section 
performs the actual transfer of data from: 
(1) an input buffer to the list items if a 
READ statement is being implemented, or (2) 
the list items to an output buffer if a 
WRITE statement is being implemented. In 
the case of a read or write requiring a 
format, the data must be converted before 
it is transferred. 



Read/Write Reguiring a Format: In process- 
ing a list item for a read requiring a 
format, the I/O list section passes control 
to the conversion routine associated with 
the conversion code for the list item. 
(The appropriate conversion routine is det- 
ermined by the portion of IHCFCOME that 
scans the FORMAT statement associated with 
the READ statement. The selection of the 
conversion routine depends on the conver- 
sion code of the list item being 
processed.) The conversion routine obtains 
data from an input buffer and converts the 
data to the form dictated by the conversion 
code. The converted data is then moved 
into the main storage address assigned to 
the list item. 



If the operation is a write requiring a 
format, the opening section passes control 
to the I/O interface to initialize the unit 
number specified in the WRITE statement for 
writing. (The unit number is passed, as an 
argument, to the opening section via the 
calling sequence. ) The I/O interface opens 
the data control block (via the OPEN 
macro-instruction) for the specified data 
set if it was not previously opened. The 



In general, after a conversion routine 
has processed a list item, the I/O list 
section determines if that routine can be 
applied to the next list item or array 
element (if an array is being processed). 
The I/O list section examines a field count 
that indicates the number of times a parti- 
cular conversion code is to be applied to 
successive list items or successive ele- 
ments of an array. 



Appendix L: Object-Time Library Subprograms 153 



Table 31. IHCFCOME FORMAT Code Processing 
r t t t — 



FORMAT Code 



Description 



Type 



Corresponding Action Upon Code by IHCFCOME 



n( 



nP 



Tn 



nX 



text* or nH 



Fw. d 
Ew. d 
Dw.d 
Iw 
Aw 



beginning of 
statement 



group count 



field count 



scaling factor 



column reset 



skip or blank 



literal data 



conversions 



control 



control 



control 



control 



control 



control 



control 



conversion 



group end 



record end 



end of 
statement 



control 



control 



control 



Save location for possible repetition of the 
format codes; clear counters. 



Save n and location of left parenthesis for 
possible repetition of the format codes in the 
group. 



Save n for repetition of format code which 
follows. 



Save n for use by F, E, and D conversions. 



Reset current position within record to nth 
column or byte. 



Skip n characters of an input record or insert n 
blanks in an output record. 



Move n characters from an input record to the 
FORMAT statement, or n characters from the 
FORMAT statement to an output record. 



Exit to the load module to return control to 
subroutine FIOLF or FIOAF. Using information 
passed to the I/O list section, the address and 
length of the current list item are obtained 
and passed to the proper conversion routine 
together with the current position in the I/O 
buffer, the scale factor, and the values of w 
and d. Upon return from the conversion routine 
the current field count is tested. If it is 
greater than 1, another exit is made to the load 
module to obtain the address of the next list 
item. 



Test group count. If greater than 1, repeat 
format codes in group; otherwise continue to 
process FORMAT statement from current position. 



Input or output one record via 
and READ/WRITE macro-instruction. 



I/O Interface 



If no I/O list items remain to be transmitted, 
return control to the load module to link to the 
closing section; if list items remain, input or 
output one record using I/O interface and READ/ 
WRITE macro- instruction. Repeat format codes 
from last parenthesis. 
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If the conversion code is to be repeated 
and if the previous list item was a vari- 
able, the I/O list section returns control 
to the load module. The load module again 
branches to the I/O list section and pass- 
es, as an argument, the main storage 
address assigned to the next list item. 



The conversion routine that processed 
the previous list item is then given con- 
trol. This procedure is repeated until 
either the field count is exhausted or the 
input data for the READ statement is 
exhausted. 



If the conversion code is to be repeated 
and if an array is being processed, the I/O 
list section computes the main storage 
address of the next element in the array. 
The conversion routine that processed the 
previous element is then given control. 
This procedure is repeated until either all 
the array elements associated with a speci- 
fic conversion code are processed or the 
input data for the READ statement is 
exhausted. 



If the conversion code is not to be 
repeated, control is passed to the scan 
portion of IHCFCOME to continue the scan of 
the FORMAT statement. If the scan portion 
determines that a group of conversion codes 
is to be repeated, the conversion routines 
corresponding to those codes are applied to 
the next portion of the input data. This 
procedure is repeated until either the 
group count is exhausted or the input data 
for the READ statement is exhausted. 



If a group of conversion codes is not to 
be repeated and if the end of the FORMAT 
statement is not encountered, the next 
format code is obtained. For a control 
type code,, control is passed to the asso- 
ciated control routine to perform the indi- 
cated operation. For a conversion type 
code, control is returned to the load 
module if the previous list item was a 
variable. The load module again branches 
to the I/O list section and passes, as an 
argument, the main storage address assigned 
to the next list item. Control is then 
passed to the conversion routine associated 
with the new conversion code. The conver- 
sion routine then processes the data for 
this list item. If the data that was just 
converted was placed into an element of an 
array and if the entire array has not been 
filled, the I/O list section computes the 
main storage address of the next element in 
the array and passes control to the conver- 
sion routine associated with the new con- 
version code. The conversion routine then 



processes the data for this array element. 
Subsequent I/O list processing for a READ 
requiring a format proceeds at the point 
where the field count is examined. 



If the scan portion encounters the end 
of the FORMAT statement and if all the list 
items are satisfied, control returns to the 
next sequential instruction within the load 
module. This instruction (part of the 
calling sequence to IHCFCOME) branches to 
the closing section. If all the list items 
are not satisfied, control is passed to the 
I/O interface to read (via the READ 
macro-instruction) the next input record. 
The conversion codes starting from the last 
left parenthesis are then repeated for the 
remaining list items. 



If the operation is a write requiring a 
format, the I/O list section processing is 
similar to that for a read requiring a 
format. The main difference is that the 
conversion routines obtain data from the 
main storage addresses assigned to the list 
items rather than from an input buffer. 
The converted data is then transferred to 
an output buffer. If all the list items 
have not been converted and transferred 
prior to the encounter of the end-of-the 
FORMAT statement, control is passed to the 
I/O interface. The I/O interface writes 
(via the WRITE macro-instruction) the con- 
tents of the current output buffer onto the 
output data set. The conversion codes 
starting from the last left parenthesis are 
then repeated for the remaining list items. 



Read/Write Not Requiring a Format; In 
processing a list item for a read not 
requiring a format, the I/O list section 
must know the main storage address assigned 
to the list item and the size of the list 
item. Their values are passed, as argu- 
ments, via the calling sequence to the I/O 
list section. The list item may be either 
a variable or an array. In either case, 
the number of bytes specified by the size 
of the list item is moved from the input 
buffer to the main storage address assigned 
to the list item. The I/O list section 
then returns control to the load module. 
The load module again branches to the I/O 
list section and passes, as arguments, the 
main storage address assigned to the next 
list item and the size of the list item. 
The I/O list section moves the number of 
bytes specified by the size of the list 
item into the main storage address assigned 
to this list item. This procedure is 
repeated either until all the list items 
are satisfied or until the input data is 
exhausted. Control is then returned to the 
load module. 
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If the operation is a write not requir- 
ing a format, the I/O list section process- 
ing is similar to that described for a read 
not requiring a format. The main differ- 
ence is that the data is obtained from the 
main storage addresses assigned to the list 
items and is then moved to an output 
buffer. 



CLOSING SECTION; The compiler generates a 
calling sequence to one of two entry points 
in the closing section of IHCFCOME each 
time it encounters the end of a READ or 
WRITE statement in the FORTRAN source 
module. The entry points correspond to the 
operations of read and write, requiring or 
not requiring a format. 



Read/Write Requiring a Format; If the 
operation is a read requiring a format, the 
closing section simply returns control to 
the load module to continue load module 
execution. If the operation is a write 
requiring a format, the closing section 
branches to the I/O interface. The I/O 
interface writes (via the WRITE 
macro-instruction) the contents of the cur- 
rent I/O buffer (the final record) onto the 
output data set. The I/O interface then 
returns control to the closing section. 
The closing section, in turn, returns con- 
trol to the load module to continue load 
module execution. 



Read/Write Not Requiring a Format; If the 
operation is a read not requiring a format, 
the closing section branches to the I/O 
interface. The I/O interface reads (via 
the READ macro- instruction) successive 
records until the end of the logical record 
being read is encountered. (A FORTRAN 
logical record consists of all the records 
necessary to contain the I/O list items for 
a WRITE statement not requiring a format.) 
When the I/O interface recognizes the end- 



of -logical- record indicator, control is 
returned to the closing section. The 
closing section, in turn, returns control 
to the load module to continue load module 
execution. 



If the operation is a write not requir- 
ing a format, the closing section inserts: 
(1) the record count (i.e., the number of 
records in the logical record) into the 
control word of the I/O buffer to be 
written, and (2) an end-cf -logical-record 
indicator into the last record of the I/O 
buffer being written. The closing section 
then branches to the I/O interface. The 
I/O interface writes (via the WRITE 
macro-instruction) the contents of this I/O 
buffer onto the output data set. The I/O 
interface then returns control to the clos- 
ing section. The closing section, in turn, 
returns control to the load module to 
continue load module execution. 



Examples of IHCFCOME READ/WRITE Statement 
Processing 



The following examples illustrate the 
opening section, I/O list section, and 
closing section processing performed by 
IHCFCOME for sequential access READ and 
WRITE statements, requiring or not requir- 
ing a format. 



Note: IHCFCOME processing for the direct 
access READ, FIND, and WRITE statements is 
essentially the same as that described for 
the sequential access READ and WRITE state- 
ments. The main difference is that for 
direct access statements, IHCFCOME branches 
to the direct access I/O interface 
(IHCDIOSE) instead of to the sequential 
access I/O interface (IHCFIOSH) . 
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READ REQUIRING A FORMAT: The processing 
performed by IHCFCOME for the following 
READ statement and FORMAT statement is 
illustrated in Table 32. 



WRITE REQUIRING A FORMAT: The processing 
performed by IHCFCOME for the following 
WRITE statement and FORMAT statement is 
illustrated in Table 33. 



READ (1,2) A,B,C 
2 FORMAT (3F12.6) 



WRITE (3,2) (D(I),I=1,3) 
2 FORMAT (3F12.6) 



Table 32. IHCFCOME Processing for a READ 
Requiring a Format 



Opening 
Section 



I/O List 
Section 



+— 



Receives control from load 
module and branches to 
IHCFIOSH to initialize data 
set for reading. 



Passes control to scan 
tion of IHCFCOME. 



por- 



Returns control 
module. 



to 



load 



Receives control from load 
module, converts input data 
for A, and moves converted 
data to A. 



Returns control 
module. 



to 



load 



Receives control from load 
module, converts input data 
for B, and moves converted 
data to B. 



Returns 
module. 



control 



to load 



Receives control from load 
module, converts input data 
for C, and moves converted 
data to C. 



Returns control 
module. 



to 



load 



Closing jl. Receives control from load 
Section I module and closes out I/O 
operation. 

Returns control to load 
module to continue load 
module execution. 



Table 33. IHCFCOME Processing for a WRITE 
Requiring a Format 



Opening 
Section 



I/O List 
Section 



Closing 
Section 



Receives control from load 
module and branches to 
IHCFIOSH to initialize data 
set for writing. 

Passes control to scan por- 
tion of IHCFCOME. 



Returns 
module. 



control to load 



Receives control from load 
module, converts D(l), and 
moves D(l) to output buffer. 



Returns control 
module. 



to 



load 



Receives control from load 
module, converts D(2), and 
moves D(2) to output buffer. 



Returns control 
module. 



to 



load 



Receives control from load 
module, converts D(3), and 
moves D(3) to output buffer. 



Returns control 
module. 



to 



load 



Receives control from load 
module and branches to 
IHCFIOSH to write contents 
of output buffer. 

Returns control to load 
module to continue load 
module execution. 



l 
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READ NOT REQUIRING A FORMAT; The process- 
ing performed by IHCFCOME for the following 
READ statement is illustrated in Table 34. 



WRITE NOT REQUIRING A FORMAT: The process- 
ing performed by IHCFCOME for the following 
WRITE statement is illustrated in Table 35. 



READ (5) X f Y,Z 



WRITE (6) <W(J),J=1,10) 



Table 34. IHCFCOME Processing for a READ 
Not Requiring a Format 



Opening 
Section 



I/O List 
Section 



Closing 
Section 



1. 



Receives control from load 
module and branches to 
IHCFIOSH to initialize data 
set for reading. 



Returns 
module. 



control 



to load 



Receives control from load 
module and moves input data 
to X. 



Returns control 
module. 



to 



load 



3. Receives control from load 
module and moves input data 
to Y. 



4 . Returns 
module. 



control 



to 



load 



5. Receives control from load 
module and moves input data 
to Z. 



6. 



Returns control 
module. 



to 



load 



1. Receives control from load 
module and branches to 
IHCFIOSH to read successive 
records until the end-of- 
logical-record indicator is 
encountered. 

2. Returns control to load 
module to continue load 
module execution. 



Table 35. IHCFCOME Processing for a WRITE 
Not Requiring a Format 



Opening 
Section 



I/O List 
Section 



|. 

Closing 
Section 



1. 



Receives control from load 
module and branches to 
IHCFIOSH to initialize data 
for writing. 



Returns 
module. 



control 



to load 



Receives control from load 
module and moves W(l) to 
output buffer. 



Returns control 
module. 



to 



load 



Receives control from load 
module and moves W(2) to 
output buffer. 



Returns control 
module. 



to 



load 



5. Receives control from load 
module and moves W(10) to 
output buffer. 



6 . Returns control 
module. 



to 



load 



1. Receives control from load 
module and branches to 
IHCFIOSH to write contents 
of output buffer. 

2. Returns control to load 
module to continue load 
module execution. 
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I/O Device Manipulation Routines 



The I/O device manipulation routines of 
IHCFCOME implement the BACKSPACE, REWIND, 
and END FILE source statements. These 
routines receive control from within the 
load module via calling sequences that are 
generated by the compiler when these state- 
ments are encountered. 

Note; The I/O device manipulation routines 
apply only to sequential access I/O devices 
(e.g., tape units). BACKSPACE, REWIND, and 
ENDFILE requests for direct access data 
sets are ignored. 

The implementation of REWIND and END 
FILE statements is straightforward. The 
I/O device manipulation routines submit the 
appropriate control request to IHCFIOSH, 
the I/O interface module. After the 
request is executed, control is returned to 
the calling routine within the load module. 

The BACKSPACE statement is processed in 
a similar fashion. However, before control 
is returned to the calling routine, it is 
determined whether the record backspaced 
over is an element of a data set that does 
not require a format. If the record is an 
element of such a data set, that record is 
read into an I/O buffer and the record 
count is obtained from its control word. 
Backspace control requests, equal in number 
to the record count, are then issued and 
control is returned to the calling routine. 
If the record is not an element of such a 
data set, control is returned directly to 
the calling routine. 



Write-to-Operator Routines 



The write-to-operator routines of 
IHCFCOME implement the STOP and PAUSE 
source statements. These routines receive 
control from within the load module via 
calling sequences generated by the compiler 
upon recognition of the STOP and PAUSE 
statements. 

STOP; A write-to-operator (WTO) macro- 
instruction is issued to display the 
message associated with the STOP statement 
on the console. Load module execution is 
then terminated by passing control to the 
program termination routine of IHCFCOME. 

PAUSE; A writ e-to-operator-with- reply 
(WTOR) macro- instruction is issued to dis- 
play the message associated with the PAUSE 
statement on the console and to enable the 
operator's reply to be transmitted. A WAIT 
macro- instruction is then issued to deter- 
mine when the operator's reply has been 



transmitted. After the reply has been 
received, control is returned to the call- 
ing routine within the load module. 



Utility Routines 



The utility routines of IHCFCOME perform 
the following functions; 

• Process object-time error messages. 

• Process arithmetic-type program inter- 
ruptions . 

• Terminate load module execution. 



PROCESSING OF ERROR MESSAGES; The error 
message processing routine (IBFERR) 
receives control from various FORTRAN 
library subprograms when they detect 
object-time errors. 

Error message processing consists of 
initializing the data set upon which the 
message is to be written and also of 
writing the message. If the type of error 
requires load module termination, control 
is passed to the termination routine of 
IHCFCOME; if not, control is returned to 
the calling routine. 



PROCESSING 



OF ARITHMETIC INTERRUPTIONS 



The arithmetic- interrupt routine (IBFINT) 
of IHCFCOME initially receives control from 
within the load module via a compiler- 
generated calling sequence. The call is 
placed at the start of the executable 
coding of the load module so that the 
interrupt routine can set up the program 
interrupt mask. Subsequent entries into 
the interrupt routine are made through 
arithmetic-type interruptions. 

The interrupt routine sets up the 
program interrupt mask by means of a SPIE 
macro-instruction. This instruction speci- 
fies the type of arithmetic interruptions 
that are to cause control to be passed to 
the interrupt routine, and the location 
within the routine to which control is to 
be passed if the specified interruptions 
occur. After the mask has been set, con- 
trol is returned to the calling routine 
within the load module. 

In processing an arithmetic interrup- 
tion, the first step taken by the interrupt 
routine is to determine its type. If 
exponential overflow or underflow has 
occurred, the appropriate indicators, which 
are referenced by OVERFL (a library 
subprogram) , are set. If any type of 
divide check caused the interruption, the 
indicator referenced by DVCHK (also a 
library subprogram) is set. 
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Regardless of the type of interruption 
that caused control to be given to the 
interrupt routine, the old program PSW is 
written out for diagnostic purposes. 

After the interruption has been proc- 
essed, control is returned to the inter- 
rupted routine at the point of interrup- 
tion. 



unit blocks contain skeletons of the data 
event control blocks (DECB) and the data 
control blocks (DCB) that are required for 
I/O operations. The unit assignment table 
is used as an index to the unit blocks . 



PROGRAM TERMINATION; The load module ter- 
mination routine (IBEXIT) Of IHCFCOME 
receives control from various library sub- 
programs (e.g., DUMP and EXIT) and from 
other IHCFCOME routines (e.g., the routine 
that processes the STOP statement) . 

This routine terminates execution of the 
load module by the following means: 

• Calling the appropriate I/O 
interface (s) to check (via the CHECK 
macro- instruction) outstanding write 
requests . 

• Issuing a SPIE macro- instruction with 
no parameters indicating that the FOR- 
TRAN object module no longer desires to 
give special treatment to program 
interruptions and does not want maska- 
ble interruptions to occur. 



the operating system 



• Returning to 
supervisor. 



IHCFIOSH 



IHCFIOSH, the object-time FORTRAN 
sequential access input/output data manage- 
ment interface, receives I/O requests from 
IHCFCOME and submits them to the appropri- 
ate BSAM (basic sequential access method) 
routines and/or open and close routines for 
execution. 



Unit Blocks 



The first reference to each unit number 
(data set reference number) by an 
input/output operation within the FORTRAN 
load module causes IHCFIOSH to construct a 
unit block for each unit number. The main 
storage for the unit blocks is obtained by 
IHCFIOSH via the GETMAIN macro-instruction. 
The addresses of the unit blocks are placed 
in the unit assignment table as the unit 
blocks are constructed. All subsequent 
references to the unit numbers are then 
made through the unit assignment table. 
Figure 90 illustrates the format of a unit 
block for a unit that is defined as a 
sequential access data set. 



r t t t n 

| ABYTE | BBYTE | CBYTE j LIVECNT 
J. -L X 



Address of Buffer 1 
Address of Buffer 2 
Current buffer pointer 
Record offset 
DECB skeleton section 



Housekeeping 
Section 



| DCB skeleton section 

l J 

Figure 90. Format of a Unit Block for a 
Sequential Access Data Set 



Chart E3 illustrates the overall logic 
and the relationship among the routines of 
IHCFIOSH. Table 37, the IHCFIOSH routine 
directory, lists the routines used in 
IHCFIOSH and their functions. 



Each unit block is divided into three 
sections: a housekeeping section, a DECB 
skeleton section, and a DCB skeleton sec- 
tion. 



BLOCKS AND TABLE USED 



IHCFIOSH uses the following blocks and 
table during its processing of sequential 
access input/output requests: (1) unit 
blocks, and (2) unit assignment table. The 
unit blocks are used to indicate I/O activ- 
ity for each unit number (i.e., data set 
reference number) and to indicate the type 
of operation requested. In addition, the 



HOUSEKEEPING SECTION; The housekeeping 
section is maintained by IHCFIOSH. The 
information contained in it is used to 
indicate data set type, to keep track of 
I/O buffer locations, and to keep track of 
addresses internal to the I/O buffers to 
enable the processing of blocked records. 
The fields of this section are: 

• ABYTE . This field, containing the data 

set type passed to IHCFIOSH by 

IHCFCOME, can be set to one of the 
following: 
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FO - Input data set requiring a format. 

FF - Output data set requiring a for- 
mat. 

00 - Input data set not requiring a 
format. 

OF - Output data set not requiring a 
format . 

• BBYTE . This field contains bits that 
are set and examined by IHCFIOSH during 
its processing. The bits and their 
meanings are as follows : 

Bit on 

- exit to IHCFCOME on I/O error 

1 - I/O error occurred 

2 - current buffer indicator 

3 - not used 

4 - end-of-current buffer indicator 

5 - blocked data set indicator 

6 - variable record format switch 

7 - not used 

• CBYTE . This field also contains bits 
that are set and examined by IHCFIOSH. 
The bits and their meanings are as 
follows : 



Bit on 



- 

1 - 

2 - 

3 - 

4 - 

5 - 

6 - 

7 - 



data control block opened 

data control block not TCLOSEd 

data control block not previously 

opened 

buffer pool attached 

data set not previously rewound 

data set not previously backspaced 

concatenation occurring — reissue 

READ 

not used 



• LIVECNT . This field indicates whether 
any I/O operation performed for this 
data set is unchecked. (A value of 1 
indicates that a previous read or write 
has not been checked; a value of 
indicates that all previous read and 
write operations for this data set have 
been checked. ) 



block. It is of the same form as the DECB 
constructed by the control program for an L 
form of an S-type READ or WRITE macro- 
instruction (refer to the publication IBM 

System/360 Operating System: Control 

Program Services ) . The various fields of 
the DECB skeleton are filled in by 
IHCFIOSH; the completed block is referred 
to when IHCFIOSH issues a read/write 
request to BSAM. The read/write field is 
filled in at open time. For each I/O 
operation, IHCFIOSH supplies IHCFCOME with: 
(1) an indication of the type of operation 
(read or write), and (2) the length of and 
a pointer to the I/O buffer to be used for 
the operation. 

DCB SKELETON SECTION: The DCB (data con- 
trol block) skeleton section is a block of 
main storage within the unit block. It is 
of the same form as the DCB constructed by 
the control program for a DCB macro- 
instruction under BSAM (refer to the 
publication IBM System/360 Operating Sys- 
tem: Control Program Services ) . The var- 
ious fields of the DCB skeleton are filled 
in by the control program when the DCB for 
the data set is opened (refer to the 
publication IBM System/360 Operating Sys- 
tem: Concepts and Facilities ) . (Standard 
default values may also be inserted in the 
DCB skeleton by IHCFIOSH. Refer to "Unit 
Assignment Table" for a discussion of when 
default values are inserted into the DCB 
skeleton. ) 



Unit Assignment Table 



The unit assignment table (IHCUATBL) 
resides on the FORTRAN system library 
(SYS1.FORTLIB) . Its size depends on the 
maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (< 99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro- 
instruction. 



• Address of Buffer 1 and Address of 
Buffer 2 . These fields contain poin- 
ters to the two I/O buffers obtained 
during the opening of the data control 



block for this data set. 



• Current Buffer Pointer. 



contains a pointer to 
currently being used. 



• Record Offset. 



the 



This field 
I/O buffer 



This field contains a 
pointer to the current logical record 
within the current buffer. 

DECB SKELETON SECTION : The DECB (data 
event control block) skeleton section is a 
block of main storage within the unit 



The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSE. It 
is included once, by the linkage editor, in 
the FORTRAN load module as a result of an 
external reference to it within IHCFIOSH 
and/or IHCDIOSE. 

The unit assignment table contains a 16 
byte entry for each of the unit numbers 
that can be referred to by the user. These 
entries differ in format depending on 
whether the unit has been defined as a 
sequential access or a direct access data 
set. 

Figure 91 illustrates the format of the 
unit assignment table. 
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T 

Unit number (DSRN) | 
being used for current | 
operation | 1 n x 16 



Unit number (DSRN) of j 
error output device j not used 
x 



UBLOCK01 field 



DSRN01 default values 



LIST01 field 



UBLOCKn field 2 



DSRNn default values 3 



LISTn field * 



4 bytes 



4 bytes 



4 bytes 



8 bytes 



4 bytes 



4 bytes 



8 bytes 



4 bytes 



*n is the maximum number of units that 
can be referred to by the FORTRAN load 
module. The size of the unit table is 
equal to (8 + n x 16) bytes. 

2 The UBLOCKn field contains either a 
pointer to the unit block constructed 
for unit number n if the unit is being 
used at object-time, or a value of 1 if 
the unit is not being used. 

3 The default values for the various unit 
numbers are specified by the user and 
are assembled into the unit assignment 
table entries during the system genera- 
tion process. The default values are 
used only by IHCFIOSH; they are ignored 
by IHCDIOSE. 

*»If the unit is defined as a direct 
access data set, the LISTn field con- 
tains a pointer to the parameter list 
that defines the direct access data set. 
Otherwise, this field contains a value 
of 1. 

Figure 91. Unit Assignment Table Format 



Because IHCFIOSH deals only with 
sequential access data sets, the remainder 
of the discussion on the unit assignment 
table is devoted to unit assignment table 
entries for sequential access data sets. 
If IHCFIOSH encounters a reference to a 
direct access data set, it is considered 
as an error, and control is passed to the 
load module termination routine of 
IHCFCOME. 

The pointers to the unit blocks created 
for sequential data sets are inserted into 
the unit assignment table entries by 
IHCFIOSH when the unit blocks are con- 
structed. 



Note; Default values are standard values 
that IHCFIOSH inserts into the appropriate 
fields (e.g., BUFNO) of the DCB skeleton 
section of the unit blocks if the user 
either: 

• Causes the load module to be executed 
via a cataloged procedure, or 

• Fails, in stating his own procedure 
for execution, to include in the DCB 
parameter of his DD statements those 
subparameters (e.g., BUFNO) he is per- 
mitted to include (refer to the publi- 
cation IBM System/360 Operating Sys- 
tem: FORTRAN IV (E) Programmer's 
Guide ) . 

Control is returned to IHCFIOSH during 
data control block opening so that it can 
determine if the user has included the 
subparameters in the DCB parameter of his 
DD statements. IHCFIOSH examines the DCB 
skeleton fields corresponding to user- 
permitted subparameters, and upon 
encountering a null field (indicating that 
the user has not specified the 
subparameter) , inserts the standard value 
(i.e., the default value) for the subpar- 
ameter into the DCB skeleton. (If the 
user has included these subparameters in 
his DD statement, the control program 
routine performing data control block 
opening inserts the subparameter values, 
before giving control to IHCFIOSH, into 
the DCB skeleton fields reserved for those 
values. ) 



BUFFERING 



All input/output operations are double 
buffered. (The double buffering scheme 
can be overriden by the user if he speci- 
fies in a DD statement: BUFN0=1.) This 
implies that during data control block 
opening, two buffers will be obtained. 
The addresses of these buffers are given 
alternately to IHCFCOME as pointers to: 

• Buffers to be filled (in the case of 
output) . 

• Information that has been read in and 
is to be processed (in the case of 
input) . 



COMMUNICATION WITH THE CONTROL PROGRAM 



In requesting services of the control 
program, IHCFIOSH uses L and E forms of 
S-type macro-instructions (refer to the 
publication IBM System/360 Operating Sys- 
tem: Control Program Services ) . 
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OPERATION 



The processing of IHCFIOSH is divided 
into five sections: initialization, read, 
write, device manipulation, and closing. 
When called by IHCFCOME, a section of 
IHCFIOSH performs its function and then 
returns control to IHCFCOME. 



Initialization 



The initialization action taken by 
IHCFIOSH depends upon the nature of the 
previous I/O operation requested for the 
data set. The previous operation possi- 
bilities are: 

• No previous operation. 

• Previous operation read or write. 

• Previous operation backspace. 

• Previous operation write end-of-data 
set. 

• Previous operation rewind. 



NO PREVIOUS OPERATION: If no previous 
operation has been performed on the unit 
specified in the I/O request, the initial- 
ization section generates a unit block for 
the unit number. The data set to be 
created is then opened (if the current 
operation is not rewind or backspace) via 
the OPEN macro-instruction. The addresses 
of the I/O buffers, which are obtained 
during the opening process and placed into 
the DCB skeleton, are placed into the 
appropriate fields of the housekeeping 
section of the unit block. The DECB 
skeleton is then set to reflect the nature 
of the operation (read or write) , the 
format of the records to be read or 
written, and the address of the I/O buffer 
to be used in the operation. 

If the requested operation is a write, 
a pointer to the buffer position, at which 
IHCFCOME is to place the record to be 
written, and the block size or logical 
record length (to accommodate blocked log- 
ical records) are placed into registers, 
and control is returned to IHCFCOME. 

If the requested operation is a read, a 
record is read, via a READ macro- 
instruction, into the I/O buffer, and the 
operation is checked for completion via 
the CHECK macro- instruction. A pointer to 
the location of the record within the 
buffer, along with the number of bytes 
read or the logical record length, are 
placed into registers, and control is 
returned to IHCFCOME. 



Note: During the opening process, control 
is returned to the IHCDCBXE routine in 
IHCFIOSH. This routine determines if the 
data set being opened is a 1403 printer. 
If it is, the RECFM field in the DCB for 
the data set is altered to machine 
carriage control (FM) . The value 144 is 
inserted into both the block size and 
record length fields in the DCB. In 
addition, a pointer to the unit block 
generated for the printer, and the physi- 
cal address of the printer are placed into 
a control block area (CTLBLK) for the 
printer within IHCFIOSH. CTLBLK also con- 
tains a third print buffer. This buffer 
is used in conjunction with the two buf- 
fers already obtained for the printer. 



Figure 
CTLBLK. 



CTLBLK 



92 illustrates the format of 



|a(BUF 3) 


T 
i 


4 


1 

bytes | 


|a (unit block) 


t 


4 


bytes j 


j. — _ _ T _ T 
| a (printer) (record length | 
|. X + _ 

j 1 FT00 | 


4 
4 


bytes j 
bytes j 


I 1 F001 


T 
X 


4 


bytes | 


| third print buffer 


|144 


bytes j 


jiUsed in the task 
j table (TIOT) search. 


input/output j 
_ j 



BUF3 



Figure 92. CTLBLK Format 



PREVIOUS OPERATION READ OR WRITE: 



If the 



previous operation performed on the unit 
specified in the present I/O request was 
either a read or write, the initialization 
section determines the nature of the pre- 
sent I/O request. If it is a write, a 
pointer to the buffer position, at which 
IHCFCOME is to place the record to be 
written, and the block size or logical 
record length are placed into registers, 
and control is returned to IHCFCOME. 

If the operation to be performed is a 
read, a pointer to the buffer location of 
the record to be processed, along with the 
number of bytes read or logical record 
length, are placed into registers, and 
control is returned to IHCFCOME. 

PREVIOUS OPERATION BACKSPACE: If the pre- 
vious operation performed on the unit spec- 
ified in the present I/O request was a 
backspace, the initialization section det- 
ermines the type of the present operation 
(read or write) and modifies the DECB 
skeleton, if necessary, to reflect the 
operation type. (If the operation type is 
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the same as that of the operation that 
preceded the backspace request, the DECB 
skeleton need not be modified. ) Subsequent 
processinq steps are the same as those 
described for "No Previous Operation," 
startinq at the point after the DECB skele- 
ton is set to reflect operation type. 

PREVIOUS OPERATION WRITE END-QF-DATA SET: 
If the previous operation performed on the 
unit specified in the present I/O request 
was a write end-of-data set, a new data set 
usinq the same unit number is to be creat- 
ed. In this case, the initialization sec- 
tion closes the data set. Then, in order 
to establish a correspondence between the 
new data set and the DD statement describ- 
ing that data set, IHCFIOSH increments the 
unit sequence number of the ddname. (The 
ddname is placed into the appropriate field 
of the DCB skeleton prior to the openinq of 
the initial data set associated with the 
unit number. ) Durinq the openinq of the 
data set, the ddname will be used to merqe 
with the appropriate DD statement. The 
data set is then opened. Subsequent proc- 
essinq steps are the same as those des- 
cribed for "No Previous Operation," start- 
inq at the point after the data set is 
opened. 

PREVIOUS OPERATION REWIND; If the previous 
operation performed on the unit specified 
in the present I/O request was a rewind, 
the ddname is initialized (set to FTxxFOOl) 
in order to establish a correspondence 
between the initial data set associated 
with the unit number and the DD statement 
describinq that data set. The data set is 
then opened. Subsequent processinq steps 
are the same as those described for "No 
Previous Operation," startinq at the point 
after the data set is opened. 



Read 



The read section of IHCFIOSH performs 
two functions: (1) reads physical records 
into the buffers obtained durinq data set 
openinq, and (2) makes the contents of 
these buffers available to IHCFCOME for 
processinq. 

If the records beinq processed are 
blocked, the read section does not read a 
physical record each time it is qiven 
control. IHCFIOSH only reads a physical 
record when all of the loqical records of 
the blocked record under consideration have 
been processed by IHCFCOME. However, if 
the records beinq processed are either 
unblocked or of u- format, the read section 
of IHCFIOSH issues a READ macro-instruction 
each time it receives control. 



The readinq of records by this section 
is overlapped. That is, while the contents 
of one buffer are being processed, a physi- 
cal record is being read into the other 
buffer. When the contents of one buffer 
have been processed, the read into the 
other buffer is checked for completion. 
Upon completion of the read operation, 
processinq of that buffer's contents is 
initiated. In addition, a read into the 
second buffer is initiated. 

Each time the read section is qiven 
control it makes the next record available 
to IHCFCOME for processinq. (In the case 
of blocked records, the record presented to 
IHCFCOME is loqical.) The read section of 
IHCFIOSH places: (1) a pointer to the 
record's location in the current I/O buf- 
fer, and (2) the number of bytes read or 
loqical record length into registers, and 
then returns control to IHCFCOME. 



Write 



The write section of IHCFIOSH performs 
two functions: (1) writes physical records, 
and (2) provides IHCFCOME with buffer space 
in which to place the records to be writ- 
ten. 

If the records being written are 
blocked, the write section does not write a 
physical record each time it is given 
control. IHCFIOSH only writes a physical 
record when all of the logical records that 
comprise the blocked record under consider- 
ation have been placed into the I/O buffer 
by IHCFCOME. However, if the records being 
written are either unblocked or of U- 
format, the write section of IHCFIOSH 
issues a WRITE macro-instruction each time 
it receives control. 

The writing of records by this section 
is overlapped. That is, while IHCFCOME is 
filling one buffer, the contents of the 
other buffer are being written. When an 
entire buffer has been filled, the write 
from the other buffer is checked for com- 
pletion. Upon completion of the write 
operation, IHCFCOME starts placing records 
into that buffer. In addition, a write 
from the second buffer is initiated. 

Each time the write section is given 
control, it provides IHCFCOME with buffer 
space in which to place the record to be 
written. IHCFIOSH places: (1) a pointer to 
the location within the current buffer at 
which IHCFCOME is to place the record, and 
(2) the block size or logical record length 
into registers, and then returns control to 
IHCFCOME. 



164 



Note: The write section checks to see if 
the data set being written on is a 1403 
printer. If it is, the carriage control 
character is changed to machine code, and 
three buffers, instead of the normal two, 
are used when writing on the printer. 

ERROR PROCESSING; If an end-of-data set or 
an I/O error is encountered during reading 
or writing, the control program returns 
control to the location within IHCFIOSH 
that was specified during data set initial- 
ization. In the case of an I/O error, 
IHCFIOSH sets a switch to indicate that the 
error has occurred. Control is then 
returned to the control program. The con- 
trol program completes its processing and 
returns control to IHCFIOSH, which interro- 
gates the switch, finds it to be set, and 
passes control to the I/O error routine of 
IHCFCOME. 

In the case of an end-of-data set, 
IHCFIOSH simply passes control to the end- 
of-data set routine of IHCFCOME. 

Chart EU illustrates the execution-time 
I/O recovery procedure for any I/O errors 
detected by the I/O supervisor. 



Device Manipulation 



The device manipulation section of 
IHCFIOSH processes backspace, rewind, and 
write end-of-data set requests. 



BACKSPACE: 



IHCFIOSH 



processes the back- 
space request by issuing a BSP (physical 
backspace) macro-instruction. It then 
places the data set type, which indicates 
the format requirement, into a register and 
returns control to IHCFCOME. (IHCFCOME 
needs the data set type to determine its 
subsequent processing.) 

REWIND: IHCFIOSH processes the rewind 
request by issuing a CLOSE macro- 
instruction, using the REREAD option. This 
option has the same effect as a rewind. 
Control is then returned to IHCFCOME. 



open. In addition, this section ensures 
that all write operations for a data set 
are completed before the data control block 
for that data set is closed. This is done 
by issuing a CHECK macro-instruction for 
all double-buffered output data sets. Con- 
trol is then returned to IHCFCOME. 



Note: If a 1403 printer is being used, a 
write from the last print buffer is issued 
to insure that the last line of output is 
written. 



IHCDIOSE 



IHCDIOSE, the object-time FORTRAN direct 
access input/output data management inter- 
face, receives I/O requests from IHCFCOME 
and submits them to the appropriate BDAM 
(basic direct access method) routines 
and/or open and close routines for execu- 
tion. (For the first I/O request involving 
a nonexistent data set, the appropriate 
BSAM routines must be executed prior to 
linking to the BDAM routines. The BSAM 
routines format and create a new data set 
consisting of blank records.) 

IHCDIOSE receives control from: (1) the 
initialization section of the FORTRAN load 
module if a DEFINE FILE statement is 
included in the source module, and (2) 
IHCFCOME whenever a READ, WRITE, or FIND 
direct access statement is encountered in 
the load module. 

Charts E5 and E6 illustrate the overall 
logic and the relationship among the rou- 
tines of IHCDIOSE. Table 38, the IHCDIOSE 
routine directory, lists the routines used 
in IHCDIOSE and their functions. 



BLOCKS AND TABLE USED 



WRITE END-OF-DATA SET: IHCFIOSH processes 
this request by issuing a CLOSE macro- 
instruction, type = T. It then frees the 
I/O buffers by issuing a FREEPOOL macro- 
instruction, and returns control to 
IHCFCOME. 



Closing 



The closing section of IHCFIOSH examines 
the entries in the unit assignment table to 
determine which data control blocks are 



IHCDIOSE uses the following blocks and 
table during its processing of direct 
access input/output requests: (1) unit 
blocks, and (2) unit assignment table. The 
unit blocks are used to indicate I/O activ- 
ity for each unit number (i.e., data set 
reference number) and to indicate the type 
of operation requested. In addition, each 
unit block contains skeletons of the data 
event control blocks (DECB) and the data 
control block (DCB) that are required for 
I/O operations. The unit assignment table 
is used as an index to the unit blocks. 
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Unit Blocks 



Bit on 



The first reference to each unit number 
(i.e., data set reference number) by a 
direct access input/output operation within 
the FORTRAN load module causes IHCDIOSE to 
construct a unit block for each of the 
referenced unit numbers. The main storage 
for the unit blocks is obtained by IHCDIOSE 
via the GETMAIN macro-instruction. The 
addresses of the unit blocks are inserted 
into the corresponding unit assignment 
table entries as the unit blocks are con- 
structed. Subsequent references to the 
unit numbers are then made through the unit 
assignment table. 

Figure 93 illustrates the format of a 
unit block for a unit that has been defined 
as a direct access data set. 



r t t t t 1 

IOTYPE |STATUSU| not | not | 4 bytes 
| | used | used | 



h- 



RECNUM 



j 4 bytes 



STATUSAl 



CURBUF 



| 4 bytes 



BLKREFA 



j 4 bytes 



STATUSB I 



NXTBUF 



j 4 bytes 



BLKREFB 



| 4 bytes 



DECBA 



| 28 bytes 



DECBB 



j 28 bytes 



DCB 



Figure 93. 



| 104 bytes 
x J 

Format of a Unit Block for a 
Direct Access Data Set 



The meanings of the various unit block 
fields are outlined below. 



IOTYPE; This field, containing the data 
set type passed to IHCDIOSE by IHCFCOME, 
can be set to one of the following: 

F0 - input data set requiring a format 

FF - output data set requiring a format 

00 - input data set not requiring a 
format 

OF - output data set not requiring a 
format 

STATUSU : This field specifies the status 
of the associated unit number. The bits 
and their meanings are as follows: 



■ 

1 ■ 

2 - 

3 • 

4-5 



6-7 



not used 

error occurred 

two buffers are being used 

data control block for data set is 

open 

10 - U form specified in DEFINE 
FILE statement 

01 - E form specified in DEFINE 
FILE statement 

11 - L form specified 
FILE statement 
not used 



in DEFINE 



Note: IHCDIOSE references only bits 1, 2, 
and 3. 

RECNUM: This field contains the number of 
records in the data set as specified in the 
parameter list for the data set in a DEFINE 
FILE statement. It is filled in by the 
file initialization section after the data 
control block for the data set is opened. 



STATUS A: 



This 



field specifies the status 
of the buffer currently being used. The 
bits and their meanings are as follows: 



Bit on 



been 



- READ macro- instruction has 

issued 

1 - WRITE macro-instruction has been 

issued 

2 - CHECK macro- instruction has been 

issued 
3-7 Not used 

CURBUF : This field contains the address of 
the DECB skeleton currently being used. It 
is initialized to contain the address of 
the DECBA skeleton by the file initializa- 
tion section of IHCDIOSE after the data 
control block for the data set is opened. 

BLKREFA: This field contains an integer 
that, indicates either the relative position 
within the data set of the record to be 
read, or the relative position within the 
data set at which the record is to be 
written. It is filled in by either the 
read or write section of IHCDIOSE prior to 
any reading or writing. In addition, the 
address of this field is inserted into the 
DECBA skeleton by the file initialization 
section of IHCDIOSE after the data control 
block for the data set is opened. 

STATUSB : This field specifies the status 
of the next buffer to be used if two 
buffers are obtained for this data set 
during data control block opening. The 
bits and their meanings are the same as 
described for the STATUSA field. However, 
if only one buffer is obtained during data 
control block opening, this field is not 
used. 
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NXTBUF : This field contains the address of 
the DECB skeleton to be used next if two 
buffers are obtained during data control 
block opening. It is initialized to con- 
tain the address of the DECEB skeleton by 
the file initialization section of IHCDIOSE 
after the data control block for the data 
set is opened. However, if only one buffer 
is obtained during data control block open- 
ing, this field is not used. 

BLKREFB; The contents of this field are 
the same as described for the BLKREFA 
field. It is filled in either by the read 
or the write section of IHCDIOSE prior to 
any reading or writing. In addition, the 
address of this field is inserted into the 
DECBB skeleton by the file initialization 
section of IHCDIOSE after the data control 
block for the data set is opened. However, 
if only one buffer is obtained during data 
control block opening, this field is not 
used. 

DECBA SKELETON ; This field contains the 
DECB (data event control block) skeleton to 
be used when reading into or writing from 
the current buffer. It is of the same form 
as the DECB constructed by the control 
program for an L form of an S-type READ or 
WRITE macro- instruction under BDAM (refer 
to the publication IBM System/360 Operating 
System; Control Program Services ) . 

The various fields of the DECBA skeleton 
are filled in by the file initialization 
section of IHCDIOSE after the data control 
block for the data set is opened. The 
completed DECB is referred to when IHCDIOSE 
issues a read or a write request to BDAM. 
For each I/O operation, IHCDIOSE supplies 
IHCFCOME with the address of and the size 
of the buffer to be used for the operation. 

DECBB SKELETON; The DECBB skeleton is used 
whenl reading into or writing from the next 
buffer. Its contents are the same as 
described for the DECBA skeleton. The 
DECBB skeleton is completed in the same 
manner as described for the DECBA skeleton. 
However, if only one buffer is obtained 
during data control block opening, this 
field is not used. 

DCB SKELETON; This field contains the DCB 
(data control block) skeleton for the asso- 
ciated data set. It is of the same form as 
the DCB constructed by the control program 
for a DCB macro- instruction under BDAM 
(refer to the publication IBM System/ 360 

Operating System; Control Program 

Services ) . 

The various fields of the DCB skeleton 
are filled in by the control program when 
the DCB for the data set is opened (refer 
to the publication IBM System/360 Operating 
System; Concepts and Facilities ) . 



Unit Assignment Table 



The unit assignment table (IHCUATBL) 
resides on the FORTRAN system library 
(SYSl.FORTLIB) . Its size depends on the 
maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (<99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro- 
instruction. 



The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSE. It 
is included once, by the linkage editor, in 
the FORTRAN load module as a result of an 
external reference to it within IHCFIOSH 
and/or IHCDIOSE. 

The unit assignment table contains a 
16-byte entry for each of the unit numbers 
that can be referred to by either IHCDIOSE 
or IHCFIOSH. These entries differ in 
format depending on whether the unit has 
been defined as a direct access or as a 
sequential access data set. Because IHCDI- 
OSE deals only with direct access data 
sets, only the entry for a direct access 
unit is shown here. (Refer to the IHCFIOSH 
section "Table and Blocks Used" , for the 
format of the unit assignment table as a 
whole.) If IHCDIOSE encounters a reference 
to a sequential access data set, it is 
considered as an error, and control is 
passed to the load module termination rou- 
tine of IHCFCOME. 

Figure 94 illustrates the unit assign- 
ment table entry format for a direct access 
data set. 



Pointer to 
(UBLOCKxx) 



unit block xx 



Default values for DSRNxx (only 
applies to sequential access 
data sets — not used by 
IHCDIOSE) 



Pointer to parameter listxx 
(LISTxx) 



4 bytes 



8 bytes 



4 bytes 



UBLOCKxx is the unit block generated 
for unit number xx. 

DSRNxx is the unit number for the 
direct access data set (xx<99). 

LISTxx is the parameter list that 
defines the direct access data set 
associated with unit number xx. 

Figure 94. Unit Assignment Table Entry for 
a Direct Access Data Set 
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The pointers to the unit blocks are 
inserted into the unit assignment table 
entries by IHCDIOSE when the unit blocks 
are constructed. 

The pointers to the parameter lists are 
inserted into the unit assignment table 
entries by IHCDIOSE when IHCDIOSE receives 
control from the initialization section of 
the FORTRAN load module being executed. 



BUFFERING 



compiler-generated calling sequence, if a 
DEFINE FILE statement is included in the 
FORTRAN source module. The file definition 
section performs the following functions: 



Checks for the redefinition 
direct access unit number. 



of each 



• Enters the address of each direct 
access unit number's parameter list 
into the appropriate unit assignment 
table entry. 

• Establishes addressability for IHCDIOSE 
within IHCFCOME. 



All direct access input/output opera- 
tions are double-buffered. (The double 
buffering scheme, may be overridden by the 
user if he specifies in his DD statements: 
BUFN0=1.) This implies that during data 
control block opening, two buffers will be 
obtained for each data set. The addresses 
of these buffers are given alternately to 
IHCFCOME as pointers to: 



Buffers to be filled 
output. 



in the case of 



• Data that has been read in and is to be 
processed in the case of input. 

Each buffer has its own DECB. This 
increases I/O efficiency by overlapping of 
I/O operations. 



Each direct access unit number appearing 
in a DEFINE FILE statement is checked to 
see if it has been defined previously. If 
it has been defined previously, the current 
definition is ignored. If it has not been 
defined previously, the address of its 
parameter list (i.e., the definition of the 
unit number) is inserted into the proper 
entry in the unit assignment table. The 
next unit number if any is then obtained. 

When the last unit number has been 
processed in the above manner, the file 
definition section stores the address of 
IHCDIOSE into the FDIOCS field within 
IHCFCOME. This enables IHCFCOME to link to 
IHCDIOSE when IHCFCOME encounters a direct 
access I/O statement. Control is then 
returned to the FORTRAN load module to 
continue normal processing. 



COMMUNICATION WITH THE CONTROL PROGRAM 



File Initialization Section 



In requesting services of the control 
program BSAM and BDAM routines, IHCDIOSE 
uses L and E forms of S-type macro- 
instructions (refer to the publication IBM 
System/360 Operating System: Control 
Program Services ) . 



The file initialization section receives 
control from IHCFCOME whenever input or 
output is requested for a direct access 
data set. The processing performed by the 
initialization section depends on whether 
an I/O operation was previously requested 
for the data set. 



OPERATION 



The processing of IHCDIOSE is divided 
into five sections: file definition, file 
initialization, read, write, and termina- 
tion. When a section receives control, it 
performs its functions and then returns 
control to the caller (either the FORTRAN 
load module or IHCFCOME) . 



NO PREVIOUS OPERATION: If no operation was 
previously requested for the data set spec- 
ified in the current I/O request, the file 
initialization section first constructs a 
unit block for the data set. (The GETMAIN 
macro- instruction is used to obtain the 
main storage for the unit block.) The 
address of the unit block is inserted into 
the appropriate entry in the unit assign- 
ment table. 



File Definition Section 



The file definition section is entered 
from the FORTRAN load module, via a 



The file initialization section then 
reads the JFCB (job file control block) via 
the RDJFCB macro-instruction. The value in 
the BUFNO field of the JFCB is inserted 
into the DCB skeleton in the unit block. 
This value indicates the number of buffers 
that are obtained for this data set when 
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its data control block is opened. If the 
BUFNO field is null (i.e., if the user did 
not include the BUFNO subparameter in the 
DD statement for this data set) , or other 
than 1 or 2, the file initialization sec- 
tion inserts a value of two into the DCB 
skeleton. 

The file initialization section next 
examines the JFCBIND2 field in the JFCB to 
determine if the data set specified in the 
current I/O request exists. If the 
JFCBIND2 field indicates that the specified 
data set does not exist, and if the current 
request is a write, a new data set is 
created. (If the current request is a 
read, an error is indicated and control is 
returned to IHCFCOME to terminate load 
module execution. If the current request 
is a find, the request is iqnored, and 
control is returned to IHCFCOME.) If the 
JFCBIND2 field indicates that the specified 
data set already exists, a new data set is 
not created. The file initialization sec- 
tion processing for a data set to be 
created, and for a data set that already 
exists is discussed in the following para- 
graphs. 

Data Set to be Created: The data control 
block for the new data set is first opened 
for the BSAM, load mode, WRITE macro- 
instruction. The BSAM WRITE macro- 
instruction is used to create a new data 
set according to the format specified in 
the parameter list for the data set in a 
DEFINE FILE statement. The data control 
block is then closed. Subsequent file 
initialization section processing after 
creating the new data set is the same as 
that described for a data set that already 
exists (refer to the section "Data Set 
Already Exists"). 

Data Set Already Exists; The data control 
block for the data set is opened for direct 
access processing by the BDAM routines. 
After the data control block is opened, the 
file initialization section fills in var- 
ious fields in the unit block: 

• The number of records in the data set 
is inserted into the RECNUM field. 



Note: If the user specifies BUFN0=1 in the 
DD statement for this data set, only one 
I/O buffer is obtained during data control 
block opening. In this case, the NXTBUF 
field, the BLKREFB field, and the DECBB 
skeleton are not used. 

Subsequent file initialization section 
processing for the case of no previous 
operation depends upon the nature of the 
I/O request (find, read, or write) . This 
processing is the same as that described 
for the case of a previous operation (refer 
to the section "Previous Operation"). 

PREVIOUS OPERATION: If an operation was 
previously requested for the data set spec- 
ified in the current I/O request, the file 
initialization section processing depends 
upon the nature of the current I/O request. 

If the current request is either a find 
or a read, control is passed to the read 
section. 

If the current request is a write, 
control is passed to the secondary entry in 
the write section. 



Read Section 



The read section of IHCDIOSE processes 
read and find requests. The read section 
may be entered either from the file ini- 
tialization section of IHCDIOSE, or from 
IHCFCOME. In either case, the processing 
performed is the same. In processing read 
and find requests, the read section per- 
forms the following functions: 

• Reads physical records into the 
buffer (s) obtained during data control 
block opening. 

• Makes the contents of these buffers 
available to IHCFCOME for processing. 

• Updates the associated variable that is 
defined in the DEFINE FILE statement 
for the data set. 



• The address of the DECB skeletons 
(DECBA and DECBB) are inserted into the 
CURBUF and the NXTBUF fields, respec- 
tively, 

• The addresses of the I/O buffers 
obtained during data control block 
opening are inserted into the appropri- 
ate DECB skeletons. 

• The address of the BLKREFA and the 
BLKREFB fields in the unit block are 
inserted into the appropriate DECB 
skeletons . 



The read section, upon receiving con- 
trol, first checks to see if the record to 
be found or read is already in an I/O 
buffer. Subsequent read section processing 
depends upon whether the record is in the 
buffer. 

RECORD IN BUFFER: If a record is in the 
buffer, the read section determines whether 
the current request is a find or a read. 

If the current request is a find, the 
associated variable for the data set is 
updated so that it points to the relative 
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position within the direct access data set 
of the record that is in the buffer. 
Control is then returned to IHCFCOME. 

If the current request is a read, the 
read operation that read the record into 
the buffer is checked for completion. The 
read section then places the address of the 
buffer and the size of the buffer into 
registers for use by IHCFCOME. The asso- 
ciated variable for the data set is updated 
so that it points to the relative position 
within the direct access data set of the 
record following the record just read. 
Control is then returned to IHCFCOME. 

RECORD NOT IN BUFFER: If a record is not 
in the buffer, the read section first 
obtains the address of the buffer to be 
used for the current request. The relative 
record number of the record to be read is 
then inserted into the appropriate BLKREF 
field in the unit block (i.e., BLKREFA or 
BLKREFB) . The proper record is then read 
from the specified data set into the buf- 
fer. Subsequent read section processing 
for the case of a record not in the buffer 
is the same as that described for a record 
in the buffer (refer to the section "Record 
In Buffer") . 

Note 1: Record retrieval can proceed con- 
currently with CPU processing only if the 
user alternates FIND statements with READ 
statements in his program. 

Note 2 : If an I/O error occurs during 
reading, the control program returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSE. The SYNADR rou- 
tine sets a switch to indicate that an I/O 
error has occurred, and then returns con- 
trol to the control program. The control 
program completes its processing and 
returns control to IHCDIOSE. IHCDIOSE 
interrogates the switch, finds it to be 
set, and passes control to the I/O error 
routine of IHCFCOME. 



Write Section 



number of the record to be written is 
inserted into the appropriate BLKREF field 
(i.e., BLKREFA or BLKREFB). (The record is 
written the next time the write section is 
entered. ) For a formatted write, the buf- 
fer is filled with blanks. For a nonfor- 
matted write, the buffer is filled with 
zeros. The write section then places the 
address of the buffer and the size of the 
buffer into registers for use by IHCFCOME. 
Control is then returned to IHCFCOME. 

PROCESSING IF ENTERED FROM IHCFCOME; Each 
time the write section is entered from 
IHCFCOME, it writes the contents of the 
buffer onto the specified data set. Subse- 
quent write section processing for entran- 
ces from IHCFCOME is the same as that 
described for entrances from the file ini- 
tialization section of IHCDIOSE (refer to 
"Processing If Entered From File Initiali- 
zation Section"). In addition, the asso- 
ciated variable is modified prior to 
returning to IHCFCOME. The associated 
variable for the data set is updated so 
that it points to the relative position 
within the direct access data set of the 
record following the record just written. 

Note 1; The writing of physical records by 
this section is overlapped. That is, while 
IHCFCOME is filling buffer A, buffer B is 
being written onto the output data set. 
When buffer A has been filled, the write 
from buffer B is checked for completion. 
Upon completion of the write operation, 
IHCFCOME starts placing data into buffer B. 
In addition, a write from buffer A is 
initiated. 

Note 2 : If an I/O error occurs during 
writing, the control program returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSE. The SYNADR rou- 
tine sets a switch to indicate that an I/O 
error has occurred, and then returns con- 
trol to the control program. The control 
program completes its processing and 
returns control to IHCDIOSE. IHCDIOSE 
interrogates the switch, finds it to be 
set, and passes control to the I/O error 
routine of IHCFCOME. 



The write section of IHCDIOSE processes 
write requests. The write section may be 
entered either from the file initialization 
section of IHCDIOSE, or from IHCFCOME. The 
processing performed by the write section 
depends upon where it is entered from. 

PROCESSING IF ENTERED FROM FILE INITIALIZA- 
TION SECTION: If the write section is 
entered from the file initialization sec- 
tion of IHCDIOSE, no writing is performed. 
The write section only provides IHCFCOME 
with buffer space in which to place the 
record to be written. The relative record 



Termination Section 



The termination section of IHCDIOSE 
receives control from the load module ter- 
mination routine of IHCFCOME. The function 
of this section is to terminate any pending 
I/O operations involving direct access data 
sets. The unit blocks associated with the 
direct access data sets are examined by 
IHCDIOSE to determine if any I/O is pend- 
ing. CHECK macro-instructions are issued 
for all pending I/O operations to insure 
their completion. 
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The data control blocks for the direct 
access data sets are closed, and the main 
storage occupied by the unit blocks is 
freed via the FREEMAIN macro-instruction. 
Control is then returned to the load module 
termination routine of IHCFCOME to complete 
the termination process. 



The ISN of the invalid source statement 
is obtained (from information in the 
calling sequence) and is then converted to 
decimal form. IHCIBERR then links to 
IHCFCOME to implement the writing of the 
following error message: 



IHCIBERR 



IHC230I - SOURCE ERROR AT ISN 

XXXX - EXECUTION FAILED 



IHCIBERR, a member of the FORTRAN system 
library (SYSl.FORTLIB) f processes object- 
time source statement errors if the LOAD 
option is specified. IHCIBERR is entered 
(via a compiler-generated calling sequence) 
when an internal sequence number (ISN) 
cannot be executed because of a source 
statement error. 



After the error message is written on 
the user-designated error output data set, 
IHCIBERR passes control to the IBEXIT rou- 
tine of IHCFCOME to terminate execution. 



Chart E7 illustrates the overall logic 
of IHCIBERR. 
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Chart EO. IHCFCOME Overall Logic and Utility Routines 



NOTE IHCFCOME IS ENTERED 

VIA CALLING SEQUENCES 
GENERATED AT 
COMPILE TIME. 



*»*» A3* ******** 
* FORTRAN * 

» LOAD MODULE * 
» ( SEE NOTE) * 

*************** 

I 



SEE TABLE 36 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH IHCFCOME ROUTINE/ 
SUBROUTINE. 



*****B3 ********** 



DETERMINE 
REQUEST TYPE 



***************** 



*************************************************************************************** 

* * * * * 

* REQUEST TYPE *CHART * MAJOR PROCESSING * SUBROUTINES CALLED * 

* *ID. * ROUTINES * * 

* * * * * 



♦SEQUENTIAL ACCESS * * 

* AND DIRECT ACCESS * E 1 A2 * FRDWF, F I OLF i 

* READ REQUIRING A * * FIOAF. FENDF 

* FORMAT * * 



* FCVII, FCVEI, FCVDI, 

* FCVFI. FCVAI 



*************************************************************************************** 



* SEQUENTIAL ACCESS * * 

* AND DIRECT ACCESS * E1A2 * FWRWFi FIOLF, 

* WRITE REQUIRING A * * FIOAFi FENDF 

* FORMAT * * 



* FCVIOi FCVEOt FCVDOi 

* FCVFO. FCVAO 



*************************************************************************************** 

* * * * * 

* SEQUENTIAL ACCESS * * * * 

* AND DIRECT ACCESS * E1F2 * FRDNF . FIOLN. * NONE * 

* READ NOT REQUIRING * * F I OAN , FENDN * * 

* A FORMAT * * * * 

* # * * * 
*************************************************************************************** 



* SEQUENTIAL ACCESS * * * * 

* AND DIRECT ACCESS * E1F2 * FWRNF, FIOLN * NONE * 

* WRITE NOT REQUIRING* * FIOAN, FENDN * * 

* A FORMAT * * * * 

* * * * * 
•**•**•**•************•••*••**•**••***•********•••*•**•***********•**•*•*************** 

* * * * * 

* DIRECT ACCESS * E1F2 * FRDNF, FENDN * NONE * 

* FIND ** * * 

* * * * * 
************•**•*••*•*•*****•*•*•*****•****•**•*****•******•**•**•••**••***•*••*****•** 

* * * * * 

* DEVICE * E2B3 * FBKSP • FRWND , FEOFM* NONE * 

* MANIPULATION * * * * 

* * * * • 
*************************************************************************************** 



* WRITE TO 

* OPERATOR 



* E2G3 * FSTOP. FPAUS 



*************************************************************************************** 



UTILITY ROUTINES 



****G1 ********* 

* FSTOP, * 
» IHCIBERR, OR * 

* IBFERR * 
*************** 



****G2*^******* 
t FORTRAN * 

* LIB. * 

* SUBPRS. * 
*************** 



****G4 ********* 
«■ FORTRAN * 

* LOAD < 

* MODULE * 
*************** 



*****H1 ********** 

* IBEXIT * 
*—•—*—*—*—*—*—*—* 
•CLOSE ALL DCBS * 

* AND TERMINATE * 

* EXECUTION * 
***************** 



I 

V 
*****H2 ********** 

* IBFERR * 
*—*—*—*—*—*—*—*—* 

* PROCESS * 

* OBJECT-TIME * 

* ERRORS * 
***************** 



»****H4 ********** 

* IBFINT * 
*—*—*—#—*—*—*—*—* 

* PROCESS * 

* ARITHMETIC * 

* INTERRUPTIONS * 
***************** 



I 

V 
****J1 ********* 



«■ JOB * 
«• SCHEDULER • 
*************** 



****J2** ******* 

* * 

* IBEXIT * 

t i 

*************** 



**** J 4 ********* 
t FORTRAN * 

* LOAD * 

* MODULE i 
*************** 
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Chart El. Implementation of READ/WRITE/FIND Source Statements 



IHCFCOME 

FRDWF/FWRWF 
»***«A2 ********** 
•PERFORM OPENING* 
•OPERATIONS FOR * 
>* READ/WRITE * 

* REQUIRING * 

* A FORMAT * 
***************** 



* PERFORM I/O * 
•LIST OPERATIONS*<- 

* ON LIST ITEM * 

* * 
***************** 



*****B4* ********* 

* * 
♦GET LIST ITEM. * 

-* CALL I/O LIST *<- 

* SECTION OF * 

* IHCFCOME * 
***************** 



LAST 
LIST 
ITEM 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED 



* CLOSE OUT * 

* I/O *< 

* OPERATION * 

* * 
***************** 



*****D4********* 
* 

* CALL CLOSING 
-* SECTION OF 

* IHCFCOME 

********••••**•* 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST 
ITEMS PROCESSED 



»***E4 ********** 

CONTINUE WITH * 

LOAD MODULE * 

EXECUTION * 



***** 
*E1 * 
» F2* 



IHCFCOME 

FRDNF/FWRNF 

*****F2** ******** 

•PERFORM OPENING* 

•OPERATIONS FOR * 

->»READ/WRITE/FIND» 

* NOT REQUIRING * 

* A FORMAT * 
***************** 



• PERFORM I/O • 
•LIST OPERATIONS»<- 

• ON LIST ITEM • 

• • 
••***•******»**•• 



*****G4********** 

♦GET LIST ITEM. * 
-* CALL I/O LIST *<- 

* SECTION OF * 

* IHCFCOME * 

******»***••»«*** 



LAST 
LIST 
ITEM 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED 



• CLOSE OUT * 

* I/O *< 

* OPERATION * 

• • 
***********••••** 



****«J4 ***•***« 
* 

* CALL CLOSING 
-* SECTION OF 

* IHCFCOME 
» 
**«***•******•« 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST 
ITEMS PROCESSLD 



ft***K4**»******* 

CONTINUE WITH * 

LOAD MODULE * 

EXECUTION * 

It*************** 
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Chart E2. Device Manipulation and Write-to-Operator Routines 



***** 

*E2 » 
* B3» 



*****B3 ********** 
** * 

•DETERMINE TYPE * 

* OF DEVICE * 

* MANIPULATION » 
» ( SEE NOTE ) * 
•*********••**••* 



THE DEVICE MANIPULATION 
ROUTINES ONLY APPLY TO 
SEQUENTIAL ACCESS DATA SETS. 
DEVICE MANIPULATION RE- 
QUESTS FOR DIRECT ACCESS 
DATA SETS ARE IGNORED. 



BACKSPACE 

I 

FBKSP 

V 

•****D 2** ******** 



REWIND 

I 

FRWND 

V 

*****D3 ********** 



ENDFILE 

I 

FEOFM 

V 

*****D4 ********** 



» IMPLEMENT * 

* BACKSPACE * 

* SOURCE * 

* STATEMENT * 
***************** 



* IMPLEMENT » 

* REWIND * 

* SOURCE * 
» STATEMENT * 
*••**•***•*•***** 



****E3*» ******* 

* FORTRAN * 
->* LOAD *<- 

# MODULE # 

••****•***•***» 



* IMPLEMENT * 
» ENDFILE * 

* SOURCE * 

* STATEMENT * 

*•**••**••***•*** 



***** 
*E2 » 
* G3* 



*****G3 ********** 

• * 
•DETERMINE TYPE * 

• OF WRITE-TO- * 

• OPERATOR • 



••*•**•*******•** 



STOP 
I 

FSTOP 

V 

*****J2 ********** 



PAUSE 

I 
FPAUS 

V 

*****J4********** 



* IMPLEMENT * 

* STOP • 

* SOURCE * 

* STATEMENT * 

•****•*•*•**•**•* 



• IMPLEMENT * 

• PAUSE • 

• SOURCE * 
« STATEMENT * 

**•**•*•**•***•** 



*#**K2**»****** 
t * 

* IBEXIT * 

* ^ 

••«••***••**••* 



•***K4 ********* 

* FORTRAN * 
» LOAD * 

* MODULE * 
••••*••*••*•••* 
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Table 36. IHCFCOME Routine/Subroutine Directory 



r t- 

| Routine/Subroutine | 



Function 



FBKSP 
FCVAI 
FCVAO 
FCVDI 
FCVDO 
FCVEI 
FCVEO 
FCVFI 
FCVFO 
FCVII 
FCVIO 
FENDF 
FENDN 
FEOFM 
FIOAF 

FIOAN 

FIOLF 

FIOLN 

FPAUS 
FRDNF 
FRDWF 
FRWND 
FSTOP 
FWRNF 
FWRWF 
IBEXIT 

IBFERR 
IBFINT 



Implements the BACKSPACE source statement. 

Reads alphameric data. 

Writes alphameric data. 

Reads double- precision data with an external exponent. 

Writes double- precision data with an external exponent. 

Reads real data with an external exponent. 

Writes real data with an external exponent. 

Reads real data without an external exponent. 

Writes real data without an external exponent. 

Reads integer data. 

Writes integer data. 

Closing section for a READ or WRITE requiring a format. 

Closing section for a READ or WRITE not requiring a format. 

Implements the ENDFILE source statement. 

I/O list section for list array of a READ or WRITE requiring a 
format . 

I/O list section for list array of a READ or WRITE not requiring a 
format. 

I/O list section for list variable of a READ or WRITE requiring a 
format. 

I/O list section for list variable of a READ or WRITE not requiring 
a format. 

Implements the PAUSE source statement. 

Opening section of a READ not requiring a format. 

Opening section of a READ requiring a format. 

Implements the REWIND source statement. 

Implements the STOP source statement. 

Opening section for a WRITE not requiring a format. 

Opening section for a WRITE requiring a format. 

Closes the data control blocks for all FORTRAN data sets that are 
still open and terminates the execution. 

Processes object-time errors. 

Processes arithmetic-type program interruptions. 
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Chart E3. IHCFIOSH Overall Logic 



» INITIALIZATION 



**** A3 »**»»*••• 
ft * 

» IHCFCOME * 

ft 4 

*************** 



DETERMINE *. 
OPERATION . 
. TYPE .» 



SEE TABLE 37 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH IHCFIOSH ROUTINE. 



**** I 
FINIT V 

*****C1 ********** 

* * 

* DECODE DSRN * 
•AND BUILD UNIT * 
•BLOCK IF NECES-* 

* SARY * 
•••••••••*••••*•• 



*****D1 ********** 

* OPEN DATA * 

* CONTROL BLOCK * 
•FOR DATA SET IF* 
•NOT PREVIOUSLY • 

* OPENED * 
***************** 



■ * DCB 
• OPENED 
•.PROPERLY 



.* ANY *. 

YES .MORE RCDS IN*. 
-♦.THIS BLOCK TO.* 
BE PROCESSED* 



r 



*****F1 *♦»»****** 

* * 

* DETERMINE * 

* RECORD FORMAT * 

* AND BLOCKING * 

* * 
***************** 



*****D2 ********** 

* READ * 
*NEXT BLOCK INTO* 

* THIS BUFFER. » 

* SWITCH BUFFER * 

* POINTERS * 
***************** 



ft***E2********« 

CHECK RESULT 
OF READ INTO 
OTHER BUFFER 

ft*************** 



r 



n 



OUTPUT 

BUFFER 

FULL 



****D3********* 

WRITE 

CONTENTS OF 

THIS BUFFER, 

SWITCH BUFFER 

POINTERS 



CHECK RESULT 

OF WRITE 

FROM OTHER 

BUFFER 



* CHECK 

* STATUS OF 

* UNIT 

* 
•*••*•**•*•*•< 



L 



* CHECK ANY * 
->* OUTSTANDING * 

* INPUT OR * 

* OUTPUT * 
***************** 



•****F 2 ********* 
* 

• ISSUE 
>• MESSAGE 

• IHC219C 



•••••••••••*•*••• 



n 



***** 

*E4 * 
* F2* 



••CURRENT OP-* 

•ERATION DEVICE 

•• MANIP. .* 






**** 

* E4 * 



EOF .* DETERMINE *. RWND 

*. OPERATION .* 

*. TYPE .* 



*****F4 ********** 

* ISSUE * 

* BACKSPACE, * 

* INDICATE DATA *- 

* SET TYPE * 

*********»»*•»•** 



*****G4********** 

* ISSUE CLOSE, * 
->* TYPE=T, WITH * 

* LEAVE OPTION * 

* # 
***************** 



U, E 



*****E5* ****** * 

► ISSUE CLOSE 
» WITH REREAD 
» OPTION 



READ 

OR 
WRITE 



****** J 1 *********** 

* READ » 

A 

• BLOCK » 

************* 



ft ****H4 ********* 

ft 

» FREE I/O 

» BUFFERS FOR 

» THIS DATA SET 

ft 

ft*************** 



n 



***** 

*E4 * 
* B2* 



*••• 

V 
*****K 1 ***•••**** 

* PASS CURRENT * 
•RECORD POINTER • 

* AND LOGICAL *- 

* RECORD LENGTH * 

* TO IHCFCOME * 
•••••*••*•••••••• 



***** 
*E4 * 
* B2* 
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Chart E4. Execution- Time I/O Recovery Procedure 



THE I/O SUPERVISOR IS ENTERED 
VIA DATA MANAGEMENT ROUTINE 
WHEN IHCFIOSH OR IHCDIOSE 
ISSUES A MACRO-INSTRUCTION. 



*E4 * 
* B2* 

* * 



•*#**B 3** ******** 



HAS AN *. YES 

OF BEEN .* 

READ .* 

.* 
*. .* 
* NO 


* I SSUE * 
>* MESSAGE *- 

* IHC217I * 

* * 
***************** 


~l 

V 

• 

* F2 

• 














**** 



**»**C1 ********** 



RETURN TO 
IHCFCOME 



•****•***•**•*• 



*#**D1 ********* 

* FORTRAN * 
► LOAD * 

* MODULE * 
*************** 

CONTINUES 

NORMAL 

PROCESSING 



*< 1<- 

*• | 



C2 *. 

.* *. 

► I/O < 
ERROR IN 

► . IOS .< 

*. .* 
*• •* 



*•*• 
I- t 
► CI * 
f * 

*••* 



*****E2 ********** 

* * 

* ISSUE * 

* MESSAGE *< 

* IHC218I * 

* * 
**••**•**•*••**** 



*•** 

*E4 * 

* F2 *-> 



***• J 
V 
*****F 2 ********** 

* * 

* PASS * 

* ABORT CODE * 

* TO SCHEDULER * 



**•*****••****••* 



*.***G2** ******* 
t * 

* SCHEDULER * 

» * 

*************** 

ISSUES ABEND 
MESSAGE AND 
THEN CONTINUES 
NORMAL PRO- 
CESSING 



*****C3 ********** 
♦DATA MANAGEMENT* 

* RETRY * 
->* APPROPRIATE *- 

* NUMBER OF * 

* TIMES * 
***************** 



***»*D3* **»***»** 

* IHCFCOME * 

* DETERMINES * 

* IF AN INVALID *<- 

* BUFFER HAS * 

* BEEN READ * 
»*******••**•*•*• 



C4 *. 
.* *. 

.* I/O 
->*. ERROR BEEN 
♦.CORRECTED^ 
*• .♦ 

♦• •♦ 
* NO 



»***#D4 ********** 

* * 

* RETURN * 
-* ABORT CODE * 

* TO IHCFCOME * 

* * 
***************** 




.* HAS *. 
. BUFFER BEEN , 
*.READ YET .* 



F3 



*. 



.* REWIND *. NO 

*.OR BACKSPACE .* 

*. BEEN .* 
♦ISSUED.* 
*. .* 
* YES 



•****G3********** 

* * 

* VOID * 

* ABORT CODE * 

* IN IHCFCOME * 

* * 
***•••****••••**• 



****H3********* 

* FORTRAN * 

* LOAD * 

* MODULE * 
*************** 

CONTINUES 

NORMAL 

PROCESSING 
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Chart E5. IHCDIOSE Overall Logic - File Definition Section 



THE FILE DEFINITION 
SECTION IS ENTERED 
FROM THE FORTRAN 
LOAD MODULE VIA A 
COMPILER-GENERATED 
CALLING SEQUENCE. 



••••A3********* 

* FORTRAN LOAD * 

* MODULE * 

* (SEE NOTE) * 
•••**•••*••**•* 

I 



SEE TABLE 38 FOR A 
BRIEF DESCRIPTION OF THE 
FUNCTION OF EACH IHCDIOSE 
ROUTINE. 



*****B3 *•**••••** 

* GET FIRST * 

* UNIT NUMBER * 
« ( DSRN ) FROM * 
•PARAMETER LIST * 



• »»»•*»*♦•*♦*»*#•»» 



•*»**C3********** 

* INSERT UNIT * 

* NUMBER'S * 
•PARAMETER LIST • 
•ADDRESS IN UNIT* 
•ASSIGNMENT TBL • 
•*•**•••••**•*••• 



D3 



• • 



». 



.» LAST UNIT •. NO 

NUMBER IN .* 

». PARAMETER.* 
•.LIST .* 
*. .» 
• YES 



****»D4 ********** 

• GET NEXT * 

• UNIT NUMBER * 
->* (DSRN) FROM * 

♦PARAMETER LIST * 

• » 
••••*#*•••••••••* 



•••••E3*«*«****** 

* • 

• ESTABLISH * 
♦LINKAGE BETWEEN* 

* IHCDIOSE AND ♦ 

♦ IHCFCOME ♦ 
•*•••*•••••***••• 



••*«F3 ********* 

* FORTRAN * 

* LOAD * 

* MODULE * 

CONTINUE NORMAL 
PROCESSING 
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Chart E6. IHCDIOSE Overall Logic 
Sections 



File Initialization, Read, Write and Termination 



••••A2********* 
» « 

• IHCFCOME « 



.« DETERMINE 
>. OPERATION 
». TYPE 



WRITE SECTION 
(PRIMARY ENTRY 
FROM IHCFCOME) 



in « 

r 



♦*** 

• * 

» K4 * 



r 



»»** 

» » 

• B2« 



•••••CI ••••••••** 

•CONSTRUCT UNIT » 

• BLOCK. INSERT • 

* ADOR OF UNIT » 
•BLOCK INTO UNIT* 
•ASSIGNMENT TBL • 
«»»«•*»»»•»•»»»»» 



***««D 1 »•••»*»••• 

• READ JOB FILE • 

• CONTROL BLOCK • 

• (JFCBJt INSERT • 

• BUFNO VALUE * 

• INTO DCB • 



•••••El ••••••••* 

• 

• EXAMINE 
•JFCBIND2 FIELD 

• IN JFCB 



IS THIS 
A FIND 
REQUEST 



*****D2 ********** 

• • 

• CHECK » 

• FOR I/O • 

• COMPLETION • 



*»»#*B3****»***»» 

• • 

• OBTAIN • 
>• ADDRESS OF » 

• INPUT BUFFER • 

• • 
••••••••••••••••• 



»»»»*C3»********* 
•INSERT RELATIVE* 
•RCO NO. OF RCD • 
•TO BE READ INTO* 
• BLKREFA OR « 
« BLKREFB FIELD • 
••••*•••••••••••• 



•**»**D3**< 



»»*»»E2** ******** 

• PLACE * 
•BUFFER POINTER • 
•AND BUFFER SIZE* 

• IN REGISTERS • 

• • 
••••a************ 



.» NEW DATA ». NO 
►. SET TO BE 
». CREATED .• 



'—I 



••WRITE REQUEST. *- 



•••••F2*« ••*•***• 

•GET ASSOCIATED • 

• VARIABLE'S • 

• ADDRESS AND •- 

• CURRENT • 

• RECORD NUMBER • 
••••••••••••••••• 



•••••G2 •••••••• 

• 

• OPEN 

>• DCB FOR NEW 

• DATA SET 



************* 



•••••E3********** 

• • 

• PLACE BUFFER • 
-• POINTER AND •< 

•BUFFER SIZE IN • 

• REGISTERS • 



IS THIS 
A FIND 
REQUEST 



WRITE 

A 

» RECORD « 

••••••••••••• 



• C4 »-> 



*»** 

»****C4********** 

• OBTAIN NEXT • 
•OUTPUT BUFFER. • 

• BLANK OR ZERO • 

• DEPENDING ON • 
•DATA SET FORMAT* 
••••••••••*•••••• 



**»**D4»* ******** 
•INSERT RELATIVE* 
•RCO NO. OF RCD • 
» TO BE WRITTEN • 
•INTO BLKREFA OR» 
• BLKREFB FIELD * 



.* ANY *. (• 
*• PENDING I/O .*- 
•OPERATIONS.* 



*****C5*** ******* 

* • 

* WAIT * 

* FOR I/O * 

* COMPLETION * 

* • 
••••••••••••••••• 



•••••DS********** 

* * 
•CLOSE DCBS FOR * 

* DIRECT ACCESS * 

* DATA SETS * 

* * 
*••*»*•**••****** 



•••••E5**»******* 

* FREE MAIN * 

* STORAGE » 

* OCCUPIED BY * 

* UNIT BLOCKS * 

* • 
*•*•***••***»**** 



->» 



•••••F4**««****** 
* UPDATE * 
•ASSOCIATED VAR • 
SO THAT IT »- 
POINTS TO RCD * 
» JUST READ * 
••••••••••••••••• 



READ 
OR PINO 
REQUEST 



•INDICATE ERROR 



••••»H2 ••••••••»• 

• CREATE » 
•AND FORMAT NEW • 
•DATA SET. USING • 

• BSAM WRITE • 

• MACRO • 
••••••••••••••••• 



CLOSE 

DCB FOR DATA 

SET 



» IHCFCOME « 
ft « 

••••••••••••••• 



• K2 »-> 

• • 
•••• 



•••••K2»»»»«»»»« 

• OPEN DCB FOR 

• DATA SET FOR 

• DIRECT ACCESS 

• PROCESSING 



***»#G3**»»****** 

• INSERT RECORD • 

• NUMBER INTO • 
->• RECNUM FIELD • 

• OF UNIT * 

• BLOCK • 



**»*»H3»»»»*«*»»* 
•INSERT ADDR OF • 
•OECBA SKELETON * 

• INTO CURBUF • 

• FIELD OF • 
» UNIT BLOCK • 
••••••••••••••••• 



»»»»»J3»*»»»*»»»« 
•INSERT AODR OF • 
•OECBB SKELETON • 

• INTO NXTBUF • 

• FIELD OF UNIT • 

• BLK IF 2 BFRS • 



»*»**K3*»»»****** 
•INSERT ADDR OF • 

• I/O BFRS • 

• INTO DECB •- 
•SKELETONS ) IN • 

• UNIT BLOCK • 



» UPDATE * 
•ASSOCIATED VAR • 
• SO THAT IT »- 
•POINTS TO NEXT • 
•RCD IN DATA SET* 
••••••••••••••••• 



»****H**»******** 

•INSERT AODR OF • 

•BLKREFA INTO • 

->*DECBA SKELETON • 

• IN UNIT • 

• BLOCK • 



»»«»F5»»»****** 
» « 

»' IHCFCOME « 

ft « 

•*«*****•»•**«* 



•INSERT ADOR OF 


• 


• BLKREFB INTO 


• 


•OECBB SKELETON 


* 


•IN UNIT BLOCK 


• 


• IF TWO BFRS 


» 


•*«» 






• • 






• K4 *-> 






* * 






•••• V 




• •• 




K4 ». 




■ • •• 


•••• 


.» WRITE ». YES • 


• • REQUEST .* >• C4 


•• •• 


* 


*. 


.* 


•••• 
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Table 37. IHCFIOSH Routine Directory 



r t- 

| Routine | 
I- 



Function 



| FCLOS 

I 

J FCNTL 

I 

j FIN IT 

I 

j FREAD 

I 

JFRITE 
I 



CHECKS double-buffered output data sets 
Services device manipulation requests. 
Initializes unit and data set. 
Services read requests. 
Services write requests. 



Table 38. IHCDIOSE Routine Directory 

r t 

| Routine | 
,. 

I DASDEF 



Function 



H 



IDASINIT 

| DASREAD 

| DASTERM 

DASTRA 
DASWRITE 



Processes DEFINE FILE statements: enters address of parameter lists into 
unit assignment table, checks for redefinition of direct access unit 
numbers, and establishes addressability for IHCDIOSE within IHCFCOME. 

Constructs unit blocks for nonopened direct access data sets, creates ana 
formats new direct access data sets, and opens data control blocks for 
direct access data sets. 

Reads physical records, passes buffer pointers and buffer size to IHCFCOME, 
and updates the associated variable. 

Checks pending I/O operations, closes direct access data sets, and frees 
main storage occupied by unit blocks. 

(Determines operation type and transfers control to appropriate routine. 

Writes physical records, provides IHCFCOME with buffer space, and updates 
the associated variable. 
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Chart E7. IHCIBERR Overall Logic 



•***A3** ******* 
► FORTRAN * 
* LOAD * 

•• MODULE * 

*************** 



IHCIBERR IS 
ENTERED VIA 
CALLING SE- 
QUENCES GEN- 
ERATED BY 
PHASE 20 AT 
COMPILE-TIME. 



*****B3********** 

* * 
•OBTAIN INTERNAL* 
•SEQUENCE NUMBER* 

* (ISN) * 

* * 
***************** 



•****C3********** 

* * 

* CONVERT ISN * 

* TO DECIMAL * 

* FORMAT * 

* * 
***************** 



»****D 3 ********** 

* BRANCH TO * 

* IHCFCOME TO * 

* HANDLE THE * 

* WRITING OF * 

* ERROR MESSAGE * 
***************** 



****E3********* 
» IBEXIT RTN * 
t OF * 
» IHCFCOME * 

*************** 



Appendix L: Object-Time Library Subprograms 181 



GLOSSARY 



a (xxxx) : Indicates the address of the sym- 
bol within parentheses. 

adjective code field : A field of an inter- 
mediate text entry that contains either an 
adjective code assigned by the compiler or 
an actual machine operation code. 

allocation table ; Used in Phase 5 to deter- 
mine the amount of main storage to be 
allocated to the dictionary and the over- 
flow table, and the internal text buffers. 



arq ument list ; 



list containing the 



addresses of arguments constructed when an 
adjective code indicating a call to a 
subprogram or statement function is detect- 
ed. 

argument list table ; Used at object-time to 
provide the starting address of the argu- 
ment list for each subprogram or statement 
function called. 

base value table ; Used at object-time to 
obtain base register values. 

BLDL table ; Provides information necessary 
for transferring control from one phase to 
the next for PRFRM compilations. 

blocking table ; Provides information neces- 
sary to deblock compiler input and to block 
compiler output for PRFRM compilations. 



DIMENSION, EQUIVALENCE, INTEGER, REAL, DOU- 
BLE PRECISION, EXTERNAL, FORMAT, and SUE- 
ROUTINE or FUNCTION. 



dictionary ; A resident table of the compil- 
er used to store information about symbols 
used in the source statements. For PRFRM 
compilations, the dictionary resides in 
main storage throughout the compilation; 
for SPACE compilations, the dictionary 
resides in main storage only through Phase 
14. 



dictionary index ; Consists of pointers to 
the first entries in the various chains 
that constitute the dictionary. 

end-of -statement indicator : An adjective 
code that signals the end of a particular 
statement to a processing phase. 

epilog table ; Used during Phase 25 when 
generating the instructions that return the 
value of variables used as parameters to 
the calling program. 

EQUIVALENCE table : Used by the routines 
that assign addresses for EQUIVALENCE 
entries. 

EQUIVALENCE text : An internal format used 
to transmit the information in an EQUIVAL- 
ENCE source statement to Phase 12. that 



bound variable : An integer variable in a may force the end of compilation. 



subscript expression that is redefined. 

branch list table for SFs and DOs : Used at 
object-time either by the instructions gen- 
erated to reference SF expansions or by the 
instructions generated to control the iter- 
ation of DO loops. 

branch list table for referenced statement 
numbers ; Used at object-time by the 
instructions generated to branch to execu- 
table statements. 

CDL ; A portion of the array displacement 
for subscripted variables. 

COMMON text : An internal format used to 
transmit the information in a COMMON source 
statement to Phase 12. 

communication area ; A central gathering 
area used to communicate information 
between the various phases of the compiler. 

declarative statement ; Any one of the fol- 
lowing statements: COMMON, DEFINE FILE, 



ESP card image : A card image containing an 
external symbol that is defined or referred 
to in the source module. 



executable statement : 



statement 



that 



causes the compiler to generate machine 
instructions . 

flush : A compile- time I/O request that 
forces the current output buffer being used 
for a blocked output data set to be writ- 
ten. 

forcing value : A value that indicates an 
operator's relative position in the hierar- 
chy of operators. 

forcing value table : Used during Phase 15 
processing to aid in the reordering of 
intermediate text entries for arithmetic 
expressions. 

hierarchy of operators : Defines the order 
in which operations must be performed in an 
arithmetic expression. 
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interface module 



between 
system. 



The communications link 

the compiler and the operating 



index mapping table ; Used during Phase 20 
processing of subscript expressions to 
maintain a record of all information perti- 
nent to the subscript expression. 

interlude : A compiler component that closes 
and then reopens the various data sets used 
by the compiler for SPACE compilations. 
(Interludes do not perform source statement 
processing.) 

intermediate text ; An internal representa- 
tion of the source statements that may 
eventually be converted to machine- language 
instructions . 



internal statement 



number : 



assigned 
compiler. 



h. number 

to each FORTRAN statement by the 



internal text buffer chain: 



series 



of 



buffers that are chained together by means 
of pointers. Constructed for the SYSUT1 
and SYSUT2 data sets if the PRFRM option is 
specified. 



variable used in a READ or 



list item : 
WRITE statement. 



load module : The output of the linkage 
editor; a program in a format suitable for 
loading into main storage for execution. 

location counter : A counter used to assign 
addresses. 

message address table : Used during Phase 30 
to aid in the generation of error and 
warning messages. 

message length table : Used during Phase 30 
to aid in the generation of error and 
warning messages. 

message text table : Used during Phase 30 to 
aid in the generation of error and warning 
messages. 



reordering of intermediate text entries for 
arithmetic expressions. 



overflow table : A resident table that con- 
tains all dimension, subscript, and state- 
ment number information within the source 
module being compiled. 

overflow table index : Consists of pointers 
to the first entries in the various chains 
that constitute the overflow table. 

p(xxxx) : Indicates a pointer to the infor- 
mation (within the parentheses) as rep- 
resented in the dictionary or the overflow 
table. 

patch table : Used to contain patch records 
if the patch facility has been enabled and 
if patch records precede the FORTRAN source 
module to be compiled. 



performance 



module : Processes compiler I/O 

and end-of-phase requests for 

The performance module 

BLDL 



requests 

PRFRM compilations. 

also contains the blocking table, the 

table, and the reset table. 



phase : Performs compiler initialization or 
actual source statement processing. 

pointer field : The last two bytes of an 
intermediate text word. It normally con- 
tains a relative pointer to a dictionary or 
overflow table entry. 

reset table : Used by the performance module 
to determine which, if any, of the record 
counts for the SYSUTl and SYSUT2 data sets 
must be reset. 

resident table : A table that remains in 
main storage throughout an entire compila- 
tion or throughout a part of a compilation. 
(The dictionary is resident only up to the 
end of Phase 14 for SPACE compilations. ) 

RLD card image : Contains information about 
an address constant used in the object 
module. 



mode/ type field : A field used in the die- routine displacement tables : Aid in the 

location of reserved word processing rou- 
tines in Phases 10D and 10E. 



tionary and intermediate text denoting the 
mode (real, integer, or double precision) 
and type (variable, array, function or 
constant) of a symbol. 



object module : The output of a single 
execution of an assembler or compiler, 
which constitutes input to the linkage 
editor. 

offset : A calculated indexing factor used 
to find the correct element in an array for 
a particular subscript expression. 

operations table : A temporary storage area 
used during Phase 15 processing in the 



SEGMAL : A resident table that contains the 
beginning and ending address of each seg- 
ment of main storage assigned to the dic- 
tionary and overflow table by Phase 5. 



SF number : Assigned to each 
encountered by Phase 14. 



source module: 



SF definition 



series of statements in 

the symbolic language of an assembler or 
compiler, which constitutes the entire 
input to a single execution of an assembler 
or compiler. 
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subscript table ; Temporary storage area 
used for subscript text encountered during 
the reordering of intermediate text words 
by Phase 15. 

subscript optimization ; The process of 
replacing the computation of a subscript 
expression at each recurrence with a ref- 
erence to its initial computation (that is, 
to the register assigned to contain the 
result of its initial computation) . 

SYSIN data set ; The source module, which is 
used as input to the compiler. 



SYSLIN 



data set ; The object module in card 
form (if the LOAD option is 



image 
specified) 



SYSUT1 data set : Used as a work data set by 
the compiler to contain intermediate text. 

SYSUT2 data set ; Used as a work data set by 
the compiler to contain intermediate text, 
and the output of Phase 8 if the ADJUST 
option is specified. 

SYSPRINT data set ; Contains list of patch 
records if any, compiler informative messa- 
ges, the source module listing if the 
SOURCE option is in effect, the storage map 



if the MAP option is in effect, the object 
module listing if the object listing option 
is in effect, and error and warning messa- 
ges if any. 

SYSPUNCH data set ; The object module in 
card image form (if the DECK option was 
specified) . 

SYS1.FORTLIB ; A partitioned data set that 
contains FORTRAN subprograms (including 
IHCFCOME, IHCFIOSH, IHCDIOSE, and IHCIBERR 
in the form of load modules. 

SYS1.LINKLIB : A partitioned data set that 
contains executable load modules, which can 
be reached via the XCTL, ATTACH, LINK, and 
LOAD macro- instruct ions. The FORTRAN IV 
(E) compiler resides on the SYS1.LINKLIB. 

TXT card image ; A card image containing 
either an instruction of the object module 
or data used in the object module. 

unit assignment table ; Used by IHCFIOSH and 
IHCDIOSE during processing of execution- 
time I/O requests. 

unit blocks ; Used by IHCFIOSH and IHCDIOSE 
during processing of execution time I/O 
requests. 
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INDEX 



ABS in-line function 

compile-time processing of 44 
Address assignment 36-37 
Adjective code 

definition of 105 

forcing values 42,43,141 

replacement of 42-43,118 
Adjective code field 

in intermediate text 105 
ADJUST option 

compiler processing for 31-32 
Adjusting source statements 31-32 
Allocation of storage 

for argument list table 48 

for branch list tables 38-39,46 

for compiler 25-26,89-90 
Allocation table 138 
AOP adjective code 

in intermediate text 122 
Argument list count 44,48 
Argument list table 

format of 145 

generation of 4 8 

use of 145 
Argument list table entry 

generation of RLD and TXT card images 
for 48 
Argument lists 

creation of 44 
Arithmetic expressions 

generation of instructions for 49 

processing of 42-44,149 

reordering of 42-44,119-120 
Arithmetic scan 

of source statements 102-103 
Arithmetic-type interruptions 

object-time processing of 159 
Array displacement 

computation of 123-125 

definition of 123 
Array element 123-125 
Array I/O list items 

object-time processing of 153-156 
Arrays 

compile-time processing of 
36-37,123-125 

maximum sizes of 125 
Assignment 

of registers 44,118-119 

of relative addresses 36-37 

of storage to the compiler 25-26,89-90 
ATTACH macro-instruction 

specifying substitute DDNAMES for 
compiler data sets via 22 



BACKSPACE statement 

compile-time processing of 41,149 

object-time implementation of 159,165 
Base value table 

format of 145 

generation of 50 



generation of RLD and TXT card images 
for 51 

object-time use of 50,145 
Base-displacement address 

definition of 37 
Basic direct access method 

object-time use of 151,152 
Basic sequential access method 

compile-time use of 9 

object-time use of 151,152 
BDAM 

(see basic direct access method) 
BLDL macro-instruction 

compile-time use of 29,136 
BLDL table 

construction of 29,136 

format of 137 

in performance module 23 

use of 136 
Block/deblock I/O buffers 26 
Blocking table 

construction of 29,136 

format of 136 

in performance module 23 

use of 136 
Bound variable 

definition of 47 

subscript optimization processing for 
47 
Branch list table for referenced statement 
numbers 

allocation of storage for 38-39 

format of 144 

generation of 38-39 

object-time use of 144 
Branch list table for statement function 
expansions and DO statements 

allocation of storage for 46 

format of 144 

generation of 50 

object-time use of 144 
BSAM 

(see basic sequential access method) 
BSP macro-instruction 

object-time use of 165 
Buffers 

chained text 26-28 

for blocked I/O 26 

in interface module 22 

object-time use of 162-165,168-170 
Build table 

(see BLDL table) 



CALL statement 

compile-time processing of 42,149 
Card image generation 17,39-40,45,48,51 
Card images 

END 17,51 

ESD 17,39,45 

RLD 17,39,45,48,51 

TXT 17,39-40,45,48,51 
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CDL 

calculation of 125 

definition of 125 

generation of literals for 47 
Chain field 

in dictionary 129 

in overflow table 132-133 
Chaining 

in dictionary 126-128 

in overflow table 131-133 

text buffers 26-28 
CHECK macro- instruction 

compile -time use of 56 

object-time use of 160,163,165,170 
Classification scan 

of source statements 101-102 
CLOSE macro-instruction 

compile-time use of 24,98-100 

object-time use of 165,171 
CLOSE macro- instruction, type=T 

compile-time use of 21,23,56,58 
Comments card image 

scanning of 101 
COMMON intermediate text 

creation of 34 

deletion of 41 

format of 109 
COMMON statement 

compile-time processing of 
33-34,36-38,149 

generation of intermediate text for 
nonsyntactical errors encountered in 
38 
Communication area 

definition of 92 

format of 92-94 

in interface module 20-21 

initialization of 30-31 
Compilation 

data sets used for 10-11 
Compilation input 

deblocking of 2 3 
Compilation output 

blocking of 23 
Compiler 

components of 9,18-19 

control flow in 11-12,15 

data sets used by 10-11 

input to 10 

input/output requests of 9,21,95,97 

main storage allocation to 25,26,89-91 

organization of 9 

output from 11,16-17 

overall operation 11-14 

relation to operating system 9 

system macro- instructions used by 9 

tables used by 126-143 
Compile-time I/O errors 

processing of 20,56 
Computation 

array displacement 123-125 

subscript 45-47 
Computed GO TO statement 

compile-time processing of 
41,45,50,117,149 
Constants 

assignment of relative addresses to 
36-37 



dictionary chains for 126-127 
Construction of resident tables 

BLDL table 29,136 

blocking table 29,136 

dictionary 30,34,36,126 

overflow table 30,34,36,131 

patch table 29,135 

SEGMAL 29,134 
Continuation card image 

scanning of 101 
CONTINUE statement 

compile-time processing of 149 
Control codes 

(see format codes) 
Control flow 

for PRFRM compilations 11-12,15 

for SPACE compilations 11,15 
Control operations routine 

definition of 21 

in interface module 21,56 
Conversion codes 

(see format codes) 
Conversion routines 

in IHCFCOME 153,155 
Counter, location 

relative address assignment use of 37 



DABS in-line function 

compile-time processing of 44 
Data control block skeleton section 

in unit blocks 160-161,166-167 
Data control blocks 

compile-time manipulation of 
23-24,96,98-100 

object-time use of 

161,163,165,167,169,171 
Data definition (DD) statement 9,98,162 
Data event control block 

compile-time use of 21 

object-time use of 161,167 
Data event control block skeleton section 

in unit clocks 160-161,166-170 
Data flow 

compiler overall 16-17 

Phase 8 31 

Phase 10D 33 

Phase 10E 35 

Phase 12 37 

Phase 14 40 

Phase 15 42 

Phase 20 46 

Phase 25 49 

Phase 30 51 
Data set reference numbers 

compile-time processing of 
34,36,39-40,115,126 

object-time creation of unit blocks for 
160,166 
Data sets 

for compiler input 10-11 

for compiler output 10-11 

manipulation of data control blocks for 
98-100 

object-time initialization of 
163-164,168-169 
DBLE in-line function 

compile-time processing of 44 
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DCB 

(see data control block) 
DCB skeleton section 

(see data control block skeleton 
section) 
DDNAMES, new 

substituting for compiler data set 
DDNAMES 22 
DECB 

(see data event control block) 
DECB skeleton section 

(see data event control block skeleton 
section) 
DECK option 

compiler output for 17 
Declarative statements 

definition of 32-33 

intermediate text for 34 
Default values 

for compiler options 20 

object-time insertion of into DCB 
skeletons 162 

system generation specification of 20 
DEFINE FILE statement 

compile-time processing of 
34,43,45,48,120-121,149 

object-time processing of 168,178 
DELETE macro-instruction 

compile-time use of 24-25,31,48 
Deleting load modules 

interface module 25 

object listing module 48 

performance module 25 

Phase 5 31 

source symbol module 25 
Device manipulation 

object-time routines for 159,165 
DFLOAT in-line function 

compile-time processing of 44 
Diagnostic messages 

compiler informative 146 

error/warning 146-148 

generation of 51 
Dictionary 

chaining in 126-127 

entry format 129 

freeing of main storage for 39 

index 127 

initialization of 30 

organization of 126 

use of 126 
Dictionary pointers 

replacement of 41,115 
Dimension entry 

in overflow table 132 
Dimension information 

array displacement use of 123-125 
Dimension part 123-125 
Dimension section 123-125 
DIMENSION statement 

compile-time processing of 33,149 
Direct access I/O data management interface 

(see IHCDIOSE library subprogram) 
Displacement 

base 37 

in arrays 123-125 
Displacement tables 

(see routine displacement tables) 



DO statement 

compile-time processing of 
41,45,47,50,149 
Double argument in-line functions 

compile-time processing of 44 
DOUBLE PRECISION statement 

compile-time processing of 33-34,149 
Double-precision constants 

assignment of relative addresses for 
36-37 

dictionary chain for 126 
DSRN 

(see data set reference number) 
Dummy subscripted variables 

subscript optimization processing of 47 
Dynamic text buffer chains 

(see text buffer chains) 

Editor 

(see linkage editor) 
Element 

in arrays 123-125 
Embedded blanks 

elimination of in source statements 32 
END card image 

generation of 51 

in object module 17 
End DO adjective code 

insertion of into intermediate text 
41,116 
End mark 

in intermediate text 43,105 
END statement 

compile-time processing of 51,149 
End-of- FORMAT statement indicator 

object-time encounter of 153,155 
End-of-logical record indicator 

object-time encounter of 156 
End-of-object module indicator 

generation of 51 

in object module 17 
End-of-phase requests 

compile-time processing of 21,23,56,58 
End-of-phase routine 

in interface module 21,56 

in performance module 23,58 
End-of- statement indicator 

(see end mark) 
ENDFILE statement 

compile-time processing of 41,149 

object-time implementation of 159 
Epilog table 

format of 142 

generation of 4 9 

use of 142 
EQUIVALENCE class 38 
EQUIVALENCE group 38 
EQUIVALENCE intermediate text 

creation of 34 

deletion of 41 

format of 110-111 
EQUIVALENCE root 38 
EQUIVALENCE statement 

compile-time processing of 34,38,149 

generation of intermediate text for 
nonsyntactical errors encountered in 
38 
EQUIVALENCE table 140 
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Error intermediate text entry 

generation of 35,45,102-103 
Error messages 

compile-time generation of 51,146-148 

object-time generation of 159 
Error recovery procedure, I/O 

compile-time 56 

object-time 177 
Errors, source statement 

intermediate text for 35,45,102-103 

messages for 51,146-148 
ESD 

(see external symbol dictionary) 
ESD card images 

generation of 17,39,45 

in object module 17 
Executable statements 

generation of intermediate text for 
34-35,105 
Execute (EXEC) statement 9,20,22 
External functions 

(see library subprograms) 
External references 

generation of ESD and RLD card images 
for 39,45 
EXTERNAL statement 

compile-time processing of 33,14 9 
External symbol dictionary 13 



Files 

(see data sets) 
FIND statement 

compile-time processing of 
35,40,114,149 

object-time processing of 
151-152,169-170 
FLOAT in-line function 

compile-time processing of 44 
Flush requests 

definition of 2 3 

performance module processing of 23,57 
Forcing value 

definition of 42 

use of 42-43 
Forcing value table 141 
Format codes 

compile-time processing of 40,74 

object-time processing of 153-155 
FORMAT intermediate text 

format of 108 

generation of 34,105 
FORMAT statement 

compile-time processing of 34,40,74,149 

object-time processing of 153-155 
FREEMAIN macro- instruction 

compile-time use of 24-26 

object-time use of 171 
FREEPOOL macro-instruction 

object-time use of 165 
Function calls 

compile-time processing of 42-44,149 
FUNCTION statement 

compile-time processing of 34,49,149 

GETMAIN macro-instruction 

compile-time use of 25,29 
object-time use of 160,166 



GO TO statement 

compile-time processing of 41,47,50,149 

Heading 

printing of 29 
Hierarchy of operators 42,119-120,140 



IABS in-line function 

compile-time processing of 44 
IF statement 

compile-time processing of 
42,45-46,50,149 
IFIX in-line function 

compile-time processing of 44 
IHCCGOTO library subprogram 45 
IHCDIOSE library subprogram 

buffering scheme of 168 

communication with control program 168 

file definition section of 168 

file initialization section of 168-169 

functions of 165 

I/O error processing of 170,177 

overall logic of 178-179 

read section of 169-170 

table and blocks used in 165-16 8 

termination section 170-171 

write section 170 
IHCFCOME library subprogram 

closing section of 156 

format scan of 153-155 

functions of 151 

generation of calling sequences to 151 

I/O device manipulation routines of 159 

I/O list section of 153,155-156 

opening section of 152-153 

overall logic of 172 

read/write routines of 152-156 

utility routines of 159-160 

write-to-operator routines of 159 
IHCFIOSH library subprogram 

buffering scheme of 162 

closing section of 165 

communication with control program 16 2 

device manipulation section of 165 

functions cf 160 

initialization section of 163-164 

I/O error processing of 165,177 

overall logic of 176 

processing for 1403 printer 163,165 

read section of 164 

table and blocks used in 160-162 

write section of 164-165 
IHCIBERR library subprogram 

functions of 171 

generation of calling sequences to 4 5 

overall logic of 181 
Images 

(see card images) 
Immediate DO parameter 

insertion of into intermediate text 
104,116 
Implied DOs 

checking of READ/WRITE statements for 
41,116 
Index 

in dictionary 30,127 

in overflow table 30,131 



Index 
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Index mapping table 142 
In-line functions 

compile-time processing of 44,119,150 
Input/output buffers 

(see buffers) 
Input/output data sets 

Csee data sets) 
Instruction generation 48-49 
Integer constants 

assignment of relative addresses to 
36-37 

dictionary chain for 126 
INTEGER statement 

compile-time processing of 33,150 
Interface module 

components of 20-22 

functions of 9 

I/O buffers in 22 

linkages to 95-96 

loaded into main storage 20 

returns from 95-96 
Interface module routines 21-22,56 
Interlude 10E 

functions of 18 
Interlude 14 

functions of 19 
Interlude 15 

functions of 19 
Intermediate text 

adjective code field 105 

COMMON intermediate text 109 

definition of 105 

EQUIVALENCE intermediate text 110-111 

FORMAT intermediate text 108 

generation of 13,34-35 

mode/type field 107 

modification of 13,115-122 

pointer field 107 

READ/WRITE/FIND intermediate text 
111-114 

reordering of 41-43,119-121 

subscript intermediate text 
108-109,121-122 
Internal statement number 

compiler assigning of 101,107 
Internal text 

(see intermediate text) 
Internal text buffer chains 

(see text buffer chains) 
Interruptions, arithmetic 

object-time processing of 159-160 
I/O error recovery procedure 

compile-time 56 

object-time 177 
I/O list items 

object-time processing of 153-155 
I/O requests 

compile-time processing of 
9,21-23,56,57 
I/O routine 

in interface module 21,56 

in performance module 22-23,57 
I/O statements 

object-time implementation of 151-171 
ISN 

(see internal statement number) 

Job (JOB) statement 9 



Keywords 

processing for if used as variables, 
arrays, or external names in source 
statements 32 



Library exponentiation subprograms 

assignment of registers for 44 

generation of ESD card images for 45 
Library subprograms 

exponentiation 45 

generation of ESD card images for 39,45 

IHCCGOTO 45 

IHCDIOSE 165-171,178-180 

IHCFCOME 151-160,172-175 

IHCFIOSH 160-165,176,180 

IHCIBERR 171,181 
LINK macro- instruct ion 

specifying substitute DDNAMES for 
compiler data sets via 22 
Linkage editor 

processing of the object module 13-14 
Linkages to interface module 95-96 
Linkages to performance module 97 
List items 

(see I/O list items) 
Literals 

assignment of relative addresses for 37 

generation of 47 

generation of TXT and RLD card images 
for 45 
LOAD macro- instruct ion 

compile-time use of 20,22,24,48 
LOAD option 

compiler output for 17 
Loading modules 

interface module 20 

object listing module 48 

performance module 22 

Phase 5 24 

source symbol module 22 
Location counter 

used in assigning relative addresses 37 



Ma chine- language instructions 

generation of 48-49 
Macro-instructions 

(see system macro- instructions) 
Main storage allocation 

for branch list tables 38-39,46 

for compiler 25-26,89-91 
Manipulation 

of compile-time data sets 21,23,98-100 

of object-time I/O devices 159,165 

of text buffer chains 22,28,57 
MAP option 

compiler output for 16 
Mask, program interrupt 

object-time setting of 159 
Meaningful blanks 

insertion into source statements 32 
Message address table 142-143 
Message length table 142 
Message text table 143 
Messages 

compile-time generation of 51,146-148 

object-time generation of 159 
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Mode /type field 

in dictionary 129 

in intermediate text 107 
Modification of compiler modules 21-22 
Modification of intermediate text 

for arithmetic expressions 
42-43,118-120 

for computed GO TO statements 117 

for DEFINE FILE statements 120-121 

for I/O statements 116 

for RETURN statements 117 

NOADJUST option 12,31-34 
NOLOAD option 46,51 
Nonexecutable statements 

(see declarative statements) 

Object listing facility 

enabling of 22 
Object listing module 19,48 
Object listing option 

compiler output for 16 

compiler processing for 22,36,48 
Object module 

components of 13,17 

generation of 13 
Object module instructions 

generation of 48-49 
Object module tables 144-145 
Object program 

(see object module) 
Object-time error messages 

generation of 159 
Object-time I/O errors 

processing of 165,170,177 
Offset 

computation of 123-125 

generation of literal for 47 
1-dimensional array 

array displacement computation of 
123-125 

overflow table entry for 132 
Opening 

of data control blocks at compile-time 
23-24,98-100 

of data control blocks at object-time 
163-164,168-169 
OPEN macro-instruction 

compile-time use of 23-24,98-100 

object-time use of 153,163,169 
Operands 

source statement scan of 102-103 
Operations table 141 
Operators 

source statement scan of 102-103 
Optimization, subscript 45-47 
Overflow table 

chaining in 131 

entry formats in 132-133 

index for 131 

initialization of 30 

organization of 131 

use of 132 



Parameter lists 

in DEFINE FILE statements 43 
generation of TXT card images for 45 



Patch facility 

enabling of 29 
Patch requests 

compile-time processing of 21-22,56 
Patch routine 

functions of 21-22 

in interface module 21-22,56 
Patch table 135 
PAUSE statement 

compile-time processing of 41,150 

object-time implementation of 159 
Performance module 

components of 22-23 

functions of 22 

linkages to 97 

loaded into main storage 22 

manipulating of text buffer chains 
22,28,57 

returns from 97 
Performance module routines 22-23,57-58 
Performance module tables 23,136-137 
Pointer field 

in intermediate text 107 
Preliminary scan 

of source statements 101 
PRFRM compilations 

blocking compiler output for 22-23,57 

constructing text buffer chains for 
26-28 

control flow for 11-12 

data control block manipulation for 
98,100 

deblocking compiler input for 22-23,57 

linkages to performance module for 97 

main storage allocation for 26,91 

obtaining main storage for 25 

opening data control blocks for 24 

restart condition for 24,26 
Print control operation requests 

compile-time processing of 21,56 



READ macro-instruction 

compile-time use of 9,56,98-100 

object-time use of 153-156,163-164,169 
READ statement, direct access 

compile-time processing of 

35,40-41,43-44,47,111-114,150 

object-time implementation of 
151-156,168-170,179 
READ statement, sequential access 

compile-time processing of 
40-41,43-44,47,111-114,150 

object-time implementation of 
151-156,163-164,176 
Real constants 

assignment of relative addresses for 
36-37 

dictionary chain for 126 
REAL statement 

compile-time processing of 33,150 
Recovery procedure, I/O error 

compile-time 56 

object-time 177 
Redefinition of integer variables 

in subscript expressions 47 
Referenced statement numbers 

branch list table for 144 
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References, external 

generation of ESD card images for 39,45 
Registers 

assignment of 44,118-119 

base 37,50 
Relative addresses 

assignment of 36-37 
Relocation dictionary 13 
Removing entries from chains 

in dictionary 128 
Reordering of intermediate text 

for arithmetic expressions 
42-43,119-120 

for computed GO TO statements 41,117 

for DEFINE FILE statements 43,120,121 

for READ/WRITE statements 41 
Replacement of dictionary pointers 41,115 
Reserved word 

dictionary section 30,126-127 
Reserved word scan 

of source statements 102-103 
Reset table 

format of 136 

in performance module 23 

use of 136 
RESETABL 

(see reset table) 
Resident tables 

BLDL table 23,29,136-137 

blocking table 23,29,136 

dictionary 126-130 

overflow table 130-133 

patch table 135 

reset table 23,136 

SEGMAL 134 
Resident table construction 

BLDL table 29,136 

blocking table 29,136 

dictionary 30,34,36,126 

overflow table 30,34,36,131 

patch table 29,135 

SEGMAL 29,134 
Restart condition 

definition of 24 

processing for 24,26 
RETURN macro- instruction 

compile-time use of 9 
RETURN statement 

compile-time processing of 
41,49,117,150 
REWIND statement 

compile-time processing of 41,150 

object-time implementation 159,165 
RLD 

(see relocation dictionary) 
RLD card images 

generation of 17,39,45,48,51 
Routine displacement tables 

format of 139 

use of 138 



SAOP adjective code 

in intermediate text 122 
Scan 

of source statements 101-104 
SEGMAL 

construction of 29 



format of 134 

use of 134 
Sequential access I/O data management 
interface 

(see IHCFIOSH library subprogram) 
SF 

(see statement functions) 
Single- argument in-line functions 

compile-time processing of 44 
SIZE option 23-26 
SNGL in-line function 

compile-time processing of 44 
Source module 

input to compiler 10-11 
Source module listing 16,31,33-34 
SOURCE option 

compiler output for 16 
Source program 

(see source module) 
Source statement adjustment 12,31-32 
Source statement scan 101-10 4 
Source symbol module 19,22,36 
Source symbol table 

creation of 17,36 
SPACE compilations 

control flow for 11 

data control block manipulation for 
98-99 

linkages to interface module for 95-96 

main storage allocation for 25,89-90 

obtaining main storage for 25-26 

opening data control blocks for 23-24 
SPIE macro-instruction 

object-time use of 159 
Statement function numbers 

assignment of 41 
Statement functions 

compile-time processing of 
35,41,42,50,145,149 
Statement number definitions 

compile-time processing of 50,144,14 9 
Statement numbers 

overflow table entries for 34,36,133 
Statement processing, compile-time 

BACKSPACE 41,149 

CALL 42,149 

COMMON 33-34,36-38,149 

CONTINUE 149 

DEFINE FILE 34,43,45,48,120-121,149 

DIMENSION 33,149 

direct access READ 

35,40-41,43-44,47,111-114,150 

direct access WRITE 

35,40-41,43-44,111-114,150 

DO 41,45,47,50,149 

DOUBLE PRECISION 33-34,149 

END 51,149 

ENDFILE 41,149 

EQUIVALENCE 34,38,110-111,149 

EXTERNAL 33,149 

FIND 35,40,114,149 

FORMAT 34,40,74,149 

FUNCTION 34,49,149 

GO TO 41,47,50,149 

IF 42,45-46,50,149 

INTEGER 33,150 

PAUSE 41,150 

REAL 33,150 
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RETURN 41,49,117,150 

REWIND 41,150 

sequential access READ 

40-41,43-44,47,111-114,150 

sequential access WRITE 
40-41,43-44,111-114,150 

STOP 41,150 

SUBROUTINE 34,49,150 
Statement processing, object- time 

BACKSPACE 159,165 

DEFINE FILE 168,178 

direct access READ 151-156,168-170,179 

direct access WRITE 151-156,168-170,179 

ENDFILE 159 

FIND 151-152,169-170 

FORMAT 153-155 

PAUSE 159 

REWIND 159,165 

sequential access READ 
151-156,163-164,176 

sequential access WRITE 
151-156,163-165,176 

STOP 159 
STOP statement 

compile-time processing of 41,150 

object-time implementation of 159 
Storage allocation 

(see main storage allocation) 
Storage allocation schematics 

for PRFRM compilations 91 

for SPACE compilations 89-90 
Storage map 

for assigned relative addresses 36 

for generated literals 46 

for implied external references 46 

for referenced statement numbers 48 

generation of 14 
Subprograms 

argument lists for 48 

epilog table for 49,142 

ESD card images for 39,45 
SUBROUTINE statement 

compile-time processing of 34,49,150 
Subscript expressions 

computation of 123-125 

optimization of 47-48 

overflow table entries for 132-133 
Subscript intermediate text 

108-109,121-122 
Subscript optimization 

statements subject to 46,82 

statements that affect 47,82 
Subscript table 141 
SYS IN 

input data set for compiler 10-11 

manipulation of 98-100 

opening of data control block for 
23,98-100 
SYSLIN 

manipulation of 98-100 

output data set for compiler 10-11,17 
SYSPRINT 

manipulation of 98-100 

opening of data control block for 
23,98-100 

output data set for compiler 10-11,17 

SYSPUNCH 

manipulation of 98-100 



output data set for compiler 10-11,17 
System macro-instructions 

used by compiler 9 
SYSUT1 

constructing text buffer chains for 

26-28 
manipulation of 98-100 
opening of data control block for 

23,98-100 
overlaying of DCB block size for 21 
work data set for compiler 10-11,16-17 
SYSUT2 

constructing text buffer chains for 

26-28 
manipulation of 98-100 
opening of data control block for 

23,98-100 
overlaying of DCB block size for 21 
work data set for compiler 10-11,16-17 



Tables 

allocation 139 

argument list 145 

base value 145 

BLDL 136-137 

blocking 136 

branch list 144 

dictionary 126-130 

epilog 142 

equivalence 140 

forcing value 140-141 

index mapping 142 

message address 142-143 

message length 142 

message text 143 

operations 141 

overflow 131-133 

patch 135 

reset 136 

resident 126-137 

routine displacement 138-139 

SEGMAL 134 

subscript 141 

unit assignment 161-162,167-168 

used by compiler 138-143 

used by object module 144-145 
Termination of compilation 

abnormal 25,56 

normal 24-25,56 
Termination of load module execution 

160,171,177 
Text 

(see intermediate text) 
Text buffer chains 

construction of for SYSUTl and SYSUT2 
data sets 26-28 

format of 27 

manipulation of by performance module 
22,28,57 

use of 28 
3-dimensional array 

array displacement compuation of 
123-125 

overflow table entry for 132 
Transient work area 

required for control program 25 
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2-dimensional array 

array displacement computation of 
123-125 

overflow table entry for 132 
TXT card image 

generation of 17,39-40,45,48,51 

in object module 17 

Unit assignment table 161-162,167-168 
Unit blocks 

for direct access data sets 165-167 

for sequential access data sets 160-161 
Unit number 

(see data set reference number) 
Unit tables 

(see unit blocks) 



Variables 

assignment of relative addresses for 

36-37 
dictionary entries for 34-36 



Warning 

definition of 103 
Warning messages 

generation of 51,103 



Work data sets 

for compiler 10-11,16-17 
WRITE macro- instruction 

compile- time use of 9,56,98-100 
object-time use of 154-156,170 
WRITE statement, direct access 
compile-time processing of 

35,40-41,43-44,111-114,150 
object-time implementaion of 
151-156,168-170,179 
WRITE statement, sequential access 
compile-time processing of 

40-41,43-44,111-114,150 
object-time implementation of 
151-156,163-165,176 
Write-to-operator routines 159 
WTO macro-instruction 

object-time use of 159 

XCTL macro- instruct ion 

compile-time use of 

11-12,15,21,23-24,56,58 
XOP adjective code 

in intermediate text 122 

Zero-addressing scheme 

used in array displacement computation 
123-125 



H 

H- 
D 
rt 
n> 

H- 

a 

CO 

> 



International Business Machines Corporation 
Data Processing Division 
112 East Post Road, White Plains, N.Y. 10601 
[USA Only] 



IBM World Trade Corporation 

821 United Nations Plaza, New York, New York 10017 

[International] 



READER'S COMMENTS 



Title: IBM System/360 Operating System 
FORTRAN IV (E) 
Program Logic Manual 



Form: Y28-6601-2 



Is the material: 

Easy to Read? 

Well organized? 

Complete? 

Well illustrated? 

Accurate? 

Suitable for its intended audience? 

How did you use this publication? 

As an introduction to the subject 

Other 



Yes 



No 



For additional knowledge 



fold 



Please check the items that describe your position: 

Customer personnel Operator 

IBM personnel Programmer 

Manager Customer Engineer 

Systems Analyst Instructor 



Sales Representative 

Systems Engineer 

Trainee 

Other 



Please check specific criticism(s) , give page number (s) , and explain below: 

Clarification on page(s) 

Addition on page(s) 

Deletion on page(s) 

Error on page(s) 

Explanation: 



fold 



FOLD ON TWO LINES, STAPLE AND MAIL 

No Postage Necessary if Mailed in U.S.A. 



Y28-6601-2 
staple 



staple 



fold 



fold 



| FIRST CLASS | 

| PERMIT NO. 81 | 

I I 

| POUGHKEEPSIE, N.Y. | 



r t 

j BUSINESS REPLY MAIL | 

J NO POSTAGE STAMP NECESSARY IF MAILED IN U.S.A. | 

L . J 



POSTAGE WILL BE PAID BY 



ATTN: 



IBM CORPORATION 
P.O. BOX 390 
POUGHKEEPSIE, N. Y. 12602 



PROGRAMMING SYSTEMS PUBLICATIONS 
DEPT. D58 



fold 



H- 
3 
ri- 
ft) 
Oi 

K- 
3 

a 



fold 



International Business Machines Corporation 
Data Processing Division 
112 East Post Road, White Plains, N.Y 10601 
[USA Only] 

IBM World Trade Corporation 

821 United Nations Plaza, New York, New York 10017 

[International] 



staple 



